Проектирование БД

← →
CodeDrunk (2014-06-25 16:32) [0]

Нужен совет по проектированию БД. К примеру таблице есть поле, которое может иметь одно из нескольких значений, например, статус товара - в наличие, под заказ и нет в наличие. Стоит ли выделять значения в отдельную таблицу?

т.е.

product(.., status_id, ...)

product_status(id, name)

product.status_id --- product_status.id

← →
Пит (2014-06-25 16:38) [1]

стоит

← →
DVM © (2014-06-25 16:38) [2]

> Стоит ли выделять значения в отдельную таблицу?

Как хочешь, удобнее наверное выделить в отдельную таблицу, особенно, если для каждого статуса товара имеется еще какая то дополнительная информация, например описание, расширенное описание и т.д. Если статусы планируется добавлять в процессе, то тут таблица уж наверное необходима.

← →
Ega23 © (2014-06-25 17:11) [3]

Если количество состояний статуса фиксировано, то может и не стоит, проще на клиенте множество сделать.
Если может расширяться в дальнейшем - выносить в отдельную таблицу.

← →
CodeDrunk (2014-06-25 17:33) [4]

Решил сделать таблицу. В этом варианте вижу существенный плюс - другим разработчикам проще будет разобраться, какие значения может принимать поле, чем рыться в юнитах и искать где они захардкожены.

Теперь сопутствующий вопрос, какой из паттернов источников данных (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;

← →
Dennis I. Komarov © (2014-06-25 19:25) [5]

Есть/Нет в наличии - это количество на складе
Под заказ - это способ оплаты

Есть склад, есть движение товара (in/out)
Количество товара есть результат его движения
Далее зависит от СУБД и объема данных

← →
Кщд (2014-06-25 19:52) [6]

самая тяжёлая операция в БД - объединение таблиц
серебряной пули нет
поэтому, если есть 100%-ная уверенность, что набор состояний фиксирован(безотносительно того три их или три миллиона), заводить отдельную таблицу не только излишне, но и неэффективно

← →
Кщд (2014-06-25 19:57) [7]

прошу прощения, проглядел: "...нужна поддержка нескольких движков, данный могут храниться и в SQLite и в других форматах..."
прошу считать "Кщд (25.06.14 19:52) [6]" - недействительным

← →
Dennis I. Komarov © (2014-06-26 14:08) [8]

> "...нужна поддержка нескольких движков, данный могут храниться
> и в SQLite и в других форматах..."

Угу, судя по контексту она так нужна...

Ну да, а кто-то не считает западло выносить всю бизнес-логику на сервер + системно-прикладные сущности.

← →
Кщд (2014-06-26 21:03) [10]

Кому оно надо, в студенческих проектах?

Проектирование БД Найти похожие ветки