Сложная сложность - Tricky Table Join - PullRequest
Новая
       14

Сложная сложность - Tricky Table Join

0 голосов
/ 13 марта 2012

Я боролся с этим конкретным набором таблиц в течение некоторого времени.Есть три таблицы (раньше было две, но нужно было добавить третью).Таблицы: Request, PartInfo и Status.Request используется клиентом через форму, которая вводит данные в таблицу.Status для наших сервисных агентов, чтобы отслеживать ход выполнения запросов клиентов.PartInfo - это новая таблица, содержащая общие данные, к которым имеют доступ обе стороны.

Хитрость заключается в том, что с каждым запросом существует текущий журнал изменений этого запроса, которые хранятся в той же таблице и связаны между собой.к первоначальному запросу в этой серии через самосоединяющийся ключ с именем FirstRequestID (который я буду сокращать до FID).То же самое верно для таблицы Status.Вот моя базовая структура таблиц в том виде, в котором я ее разработал ( Примечание: еще не поздно изменить архитектуру, если есть лучший подход ): 

Request          PartInfo          Status
-------          --------          ------
ID               ID                ID
FID              FID               FID
PartInfoID       PartNum           PartInfoID
ProductID        Revision          StatusID
CategoryID       Description       Comments

Теперь скажите, что я хочудля отображения информации о конкретном запросе (включая сведения о детали и изменения состояния) в таблице ASP.NET GridView.«Особый запрос» идентифицируется FID.

Вопрос : Как я могу убедиться, что, когда я просматриваю либо историю запросов, либо историю статуса, она всегда тянетправильная информация из таблицы PartInfo (общая)?Другими словами, каков наилучший способ связать эти три таблицы с надлежащими отношениями, не имея 50 разных соединительных таблиц для учета всех исключений?

1 Ответ

1 голос
/ 13 марта 2012

Я прошу прощения, но мой первый взгляд на эту схему был «это беспорядок».Эти данные должны быть нормализованы.К сожалению, здесь недостаточно информации, чтобы определить, как лучше всего это сделать.Основываясь на ваших описаниях и названиях деталей, я придумываю следующие идеи.

  • Основной сущностью является Запрос.
  • Запросы содержат продукты
  • Запросы содержат категории(если Категория не является атрибутом Продукта)
  • Продукты содержат Части (если категории не содержат Части)
  • Подразумевается, что Запрашиваемый продукт связан с произвольным количеством Частей (в отличие от стандартизированного набора деталей для этого продукта).
  • Состояние используется для отслеживания изменений состояния запроса с течением времени (и не полностью зависит от продуктов, категорий или деталей)

Это наводит на мысль о следующих таблицах 

REQUESTS
RequestId
DateTimeCreated

PRODUCTS
ProductId
--  Add CategoryId, if it’s a Product attribute

CATEGORIES
CategoryId

REQUESTPRODUCTS
RequestProductId
RequestId
ProductId
DateTimeAdded
--  Add StatusId if a status entry must be made every time a product is requested
--  Note extra surrogate key. ReqeustId + ProductId + DateTimeAdded should be the
--   natural key, unless two identical products can be requested at the same time
--   (in which case add an “Quantity” column)


REQUESTCATEGORIES
RequestId
CategoryId
DateTimeAdded
--  Suorrogate key optional, as it’s not referenced by other tables
--  Drop, if categories are product attributes

PARTS
PartId

REQUESTPRODUCTPARTS
RequestProductId
PartId
--  Add StatusId if a status entry must be made every time a part is requested

STATUS
StatusId
RequestId
DateTimeAdded
Comments

Есть журнал путей, которыми это может пойти.Вы можете получить множество таблиц «соединений», но тогда ваши данные будут иметь ссылочную целостность, и точные запросы SQL станут намного проще писать.

...