Разработка схемы базы данных для простой базы данных SQL Server 2008 - PullRequest
0 голосов
/ 18 января 2010

Я разместил это на ServerFault, и мне сказали, что это будет лучшим местом для него.

У меня есть некоторый опыт работы в качестве разработчика, но я новичок в вопросах администрирования SQL и проектирования баз данных.

Я преобразую процесс заказа и цитирования моей компании из электронной таблицы Excel во что-то более надежное, используя приложение ASP.NET с SQL-сервером.

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

В моей схеме 5 таблиц

  • CompanyProducts
  • OEMProducts
  • SupplierProducts
  • Поставщики
  • ОЙ

OEMProdcuts содержит информацию от производителя оборудования, такого как Cisco, для сетевого оборудования или Dell для серверного оборудования.

SupplierProducts содержит информацию о поставщиках, от которых мы получаем товары OEM (поскольку многие реселлеры используют OEM)

companyProducts содержит идентификатор продукта, специфичный для нашей компании.

Вот снимок из SQL Server Management Studio:

альтернативный текст http://i102.photobucket.com/albums/m108/ArkhamFreak/schema2.jpg

Мой вопрос:

Как лучше всего настроить первичные ключи для этой простой схемы? Следует ли использовать поле автоинкремента в качестве GUID, как показано на схеме, или OEMProductID для первичного ключа для ссылки во всех таблицах?

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

Спасибо за ваше время.

1 Ответ

1 голос
/ 18 января 2010

Ну и несколько мыслей:

  • Я бы определенно не использовал SupplierName в качестве первичного ключа для вашей таблицы поставщиков. Используйте что-то еще - либо у вас есть какой-то конкретный предмет (например, «Номер поставщика» из какой-то другой системы), который вы можете использовать, либо, если нет, они просто используют простой INT (возможно, с ИДЕНТИЧНОСТЬЮ) для уникальной квалификации каждого поставщика

  • То же самое касается Product (используйте ProductID, если он уникален и стабилен) и OEM (снова: используйте какой-то определенный, уникальный элемент информации, но не имя, или создайте свой свой собственный "OEM ID")

  • Почему у вас есть ProductProductID и OEMProductID на вашем SupplierProducts столе? Для этого может быть веская причина, но для меня это не очевидно с первого взгляда.

Мне лично не нравится чрезмерно использовать GUID - они громоздки, они большие и толстые (по сравнению с INT), они имеют всевозможные неприятные последствия в ваших индексах SQL Server (фрагментация индекса и таблицы) - поэтому, если у вас нет действительно веской причины для GUID (например, репликация между несколькими физическими местоположениями), я обычно предпочитаю использовать INT - либо идентификаторы, которые я генерирую сам, либо оставляю для обработки базу данных (INT IDENTITY).

...