| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Проектирование БД
CodeDrunk © (2014-06-25 16:32:00)Нужен совет по проектированию БД. К примеру таблице есть поле, которое может иметь одно из нескольких значений, например, статус товара - в наличие, под заказ и нет в наличие. Стоит ли выделять значения в отдельную таблицу?
т.е.
product(.., status_id, ...)
product_status(id, name)
product.status_id --- product_status.id
Dennis I. Komarov (2014-06-26 23:16:00) [1]Кому оно надо, в студенческих проектах?
Кщд (2014-06-26 21:03:00) [2]>Jeer © (26.06.14 15:45) [9]
да, мы такие
Jeer (2014-06-26 15:45:00) [3]Ну да, а кто-то не считает западло выносить всю бизнес-логику на сервер + системно-прикладные сущности.
Dennis I. Komarov (2014-06-26 14:08:00) [4]
> "...нужна поддержка нескольких движков, данный могут храниться
> и в SQLite и в других форматах..."
Угу, судя по контексту она так нужна...
Кщд (2014-06-25 19:57:00) [5]прошу прощения, проглядел: "...нужна поддержка нескольких движков, данный могут храниться и в SQLite и в других форматах..."
прошу считать "Кщд (25.06.14 19:52) [6]" - недействительным
Кщд (2014-06-25 19:52:00) [6]самая тяжёлая операция в БД - объединение таблиц
серебряной пули нет
поэтому, если есть 100%-ная уверенность, что набор состояний фиксирован(безотносительно того три их или три миллиона), заводить отдельную таблицу не только излишне, но и неэффективно
Dennis I. Komarov (2014-06-25 19:25:00) [7]Есть/Нет в наличии - это количество на складе
Под заказ - это способ оплаты
Есть склад, есть движение товара (in/out)
Количество товара есть результат его движения
Далее зависит от СУБД и объема данных
CodeDrunk (2014-06-25 17:33:00) [8]Решил сделать таблицу. В этом варианте вижу существенный плюс - другим разработчикам проще будет разобраться, какие значения может принимать поле, чем рыться в юнитах и искать где они захардкожены.
Теперь сопутствующий вопрос, какой из паттернов источников данных (Data Mapper, Active Record, Table Data Gateway, Row Data Gateway) разумнее всего использовать для бзаимодейсвия с бд (нужна поддержка нескольких движков, данный могут храниться и в SQLite и в других форматах).
Склоняюсь к DataMapper, но можно ли его использовать, если в класса маппера будут отсутстовать INSERT, UPDATE и DELETE методы:
{ TProduct_Status }
TProduct_Status = class
private
FId: Integer;
FName: string;
public
constructor Create(const Id: Integer; const Name: string);
property Id: Integer read FId;
property Name: string read FName;
end;
{ TProduct_Status_SQLite_Mapper }
TProduct_Status_SQLite_Mapper = class
public
procedure FindAll: TArray<TProduct_Status>;
procedure FindWithId(const Id: Integer): TArray<TProduct_Status>;
procedure FindWithName(const Name: string): TArray<TProduct_Status>;
end;
Ega23 (2014-06-25 17:11:00) [9]Если количество состояний статуса фиксировано, то может и не стоит, проще на клиенте множество сделать.
Если может расширяться в дальнейшем - выносить в отдельную таблицу.
Пит (2014-06-25 16:38:00) [10]стоит
DVM (2014-06-25 16:38:00) [11]
> Стоит ли выделять значения в отдельную таблицу?
Как хочешь, удобнее наверное выделить в отдельную таблицу, особенно, если для каждого статуса товара имеется еще какая то дополнительная информация, например описание, расширенное описание и т.д. Если статусы планируется добавлять в процессе, то тут таблица уж наверное необходима.
| |
