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

Я хочу записать программное обеспечение предприятия, и теперь я нахожусь в стадии проектирования DB. Программное обеспечение будет иметь некоторые основные данные, такие как Поставщики, Клиенты, Материально-технические ресурсы, банкиры...

Я рассматривающий 2 возможности:

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

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

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

1
задан Thang Nguyen 9 June 2010 в 17:17
поделиться

2 ответа

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

1
ответ дан 2 September 2019 в 23:53
поделиться

логически каждая «главная» сущность должна находиться в своей собственной таблице

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

1
ответ дан 2 September 2019 в 23:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: