Разработка БД для мастер-файла в программном обеспечении предприятия

Question

Я хочу написать программное обеспечение для предприятия, и сейчас я нахожусь на этапе проектирования БД.Программное обеспечение будет иметь некоторые основные данные, такие как поставщики, клиенты, запасы, банкиры ...

Я рассматриваю 2 варианта:

• Положите каждый из них на отдельную таблицу,Преимущество: таблица будет содержать всю необходимую информацию для такого типа мастер-файла (Заказчик: имя, адрес, ... / Инвентарь: Тип, Производитель, Состояние ...).Недостаток: не гибкий.Когда я хочу иметь новый тип основных данных, например, Insurer, я должен спроектировать другую таблицу.

• Поместить все в одну таблицу, и у этой таблицы есть внешний ключ к другой таблице, котораяиметь тип каждого вида основных данных (таблица 1: идентификатор, тип_данных, код, имя, адрес ....; таблица 2: тип_данных, тип_данных_наименования).Преимущество: гибкий - если мне нужно больше основных данных, таких как Страховщик, я просто помещаю в таблицу 2: код: 002, имя: Страховщик, а затем помещаю детали каждого страховщика в таблицу 1).Недостаток: в таблице 1 должно быть достаточно поля для хранения всех видов информации, включая: имя клиента, адрес, учетную запись, производителя инвентаря, качество инвентаря ...).

Так какой метод вы используете?как правило (или вы думаете, работать лучше).Большое спасибо

Answer 1

Я бы посоветовал создавать отдельные таблицы для каждого типа сущности - в будущем будет намного легче поддерживать, когда вы обнаружите вещи, которые вы хотите добавить для одного типа сущности, которые не применяются к другим.Если все объекты (поставщики, клиенты и т. Д.) Будут иметь одинаковые поля, и единственное различие заключается в их типе, то теоретически можно использовать одну таблицу.Однако я ожидаю, что между типами сущностей будет достаточно различий, поэтому стоило бы создать отдельные таблицы для каждой из них.Если есть несколько общих полей (например, информация об адресе), вы можете создать таблицу для общих элементов и иметь внешний ключ в отдельных таблицах для таблицы с общими данными (например, AddressID).

Answer 2

логически, каждая "главная" сущность должна быть в своей собственной таблице

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