Дизайн базы данных - Советы - Как бы вы это сделали? - PullRequest
Новая
       36

Дизайн базы данных - Советы - Как бы вы это сделали?

0 голосов
/ 22 марта 2011

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

Они хотят добавить возможность добавлять файловые вложения к различным объектам в базе данных, но файлы будут храниться в файловой системе.,Объекты, которые они хотели бы прикрепить к файлам (один ко многим), являются такими, и они хотят, чтобы каждое вложение учитывалось в базе данных (указатель имя файла с root_mount_point является динамическим параметром. Как я буду синхронизировать его, это мой следующий кошмар. Но я 'Мне не терпится использовать таблицу «многие» для вложений «один ко многим» для клиента, учетной записи, поставщика или счета-фактуры. 

create table client {
  client_id      char(11)   not null,
  ...
}

create table account {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  ...
}

create table vendor {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
    ...
}

create table invoice {
  client_id      char(11)   not null,
  account_number char(22)   not null,
  vendor_number  char(15)   not null,
  invoice_number char(22)   not null,
  invoice_date   datetime   not null (yes this is part of PK)
  ...
}

Каждый из них - один ко многим, пока вы работаете на своем путивниз.

Я подумываю сделать что-то подобное для таблицы "file_attachment", которая может быть множеством таблиц для любой из четырех сущностей, в зависимости от того, какие столбцы равны NULL. Если столбцы Invoice равны NULL, то вложениепоставщику и т. д. 

create table NEW_ENTITY_ATTACHMENT {
   attach_id           char(11)   not null   (dummy key, but keeping their char 11 standard),
   attach_status_cd    char(1)    not null,   ( "A"ctive or "D"eleted ) ,etc.
   attach_status_date  datetime   not null,  (they want complete history, soft deletes, and restores)
   client_id           char(11)   not null,
   account_number      char(22),
   vendor_number       char(15),
   invoice_number      char(22),
   invoice_date        datetime,
   attachment_filename char(blah blah),
   ..
   .. 
   blah
}

Таким образом, требуются первые три столбца, обязательный client_id и необязательная учетная запись, поставщик, счет-фактура в зависимости от того, на каком уровне хранится вложение.

Являюсь ли яот моего размышления здесь, должно ли быть много таблиц для КАЖДОГО объекта (например, вложение клиента, вложение аккаунта, вложение продавца, счет-фактура)Приложение?Если это ответ, они все равно не хотят его слышать, поэтому я облажался.

Я не задаю много вопросов, но с благодарностью принимаю любые предложения.Имейте в виду, что этот клиент просто хочет, чтобы он это сделал, он считает, что это проект на один-два дня, включая модель данных, графический интерфейс пользователя и серверную часть.Это Sybase ASE15, если это имеет значение.

Заранее спасибо.R

Ответы [ 2 ]

1 голос
/ 22 марта 2011

Учитывая ключевые структуры других таблиц, имеет смысл поместить все ваши вложения в одну таблицу. Например, вы сможете запросить все вложения, которые принадлежат клиенту (на всех уровнях), выбрав только client_id, а вложения, которые принадлежат клиенту (только на этом уровне), выбрав client_id и account_number IS NULL. ,

Единственная проблема, которую я вижу, это ключ к вашей новой таблице:
Использование даты как части ключа (attach_status_date) делает меня некомфортным (и, очевидно, делает вас слишком неудобным из-за вашего комментария о invoice_date).

Будет ли attach_id уникальным? Если нет, то даже с attach_status_date как частью вашего ключа вы можете не получить уникальный ключ. Если он будет уникальным (возможно, GUID?), То указывать в качестве ключа ключ attach_status_date не нужно, особенно если учесть, что вы не будете ссылаться на это поле. Может быть, это нужно просто проиндексировать?

1 голос
/ 22 марта 2011

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

Таблица вложений, вероятно, должна быть отдельной таблицей.Добавьте nullable attachment_id к каждому объекту, который может иметь вложение.Если у сущности может быть несколько вложений, используйте вместо столбца таблицу отношений «многие ко многим».

...