Оптимизация / нормализация базы данных - внешний ключ появляется в «слишком многих» таблицах - PullRequest
Новая
       49

Оптимизация / нормализация базы данных - внешний ключ появляется в «слишком многих» таблицах

2 голосов
/ 30 декабря 2011

Я провел довольно много исследований, и я полагаю, что моя база данных находится в 4-м Национальном Федеральном округе (мне сказали, что нет необходимости идти дальше), но что-то все еще не так.

У меня есть таблица TRUNK, на которую две таблицы ссылаются через внешний ключ: RATECARD, так как одна магистраль может использоваться во многих картах скоростей (различие - это время, когда действует, планы вызовов и т. Д.); кроме того, у меня есть RATEBUYINGINFO, который в основном содержит информацию, которую вы загружаете от магистральных провайдеров, и содержит информацию о тарифах для различных пунктов назначения и аналогичных. Очевидно, что с одной магистралью может быть связано больше объектов RATEBUYINGINFO, так как цена со временем меняется, но RATEBUYINGINFO и RATECARD не имеют прямого соединения, за исключением того, что они могут ссылаться на одну магистраль, поэтому в обеих этих таблицах есть TrunkID в качестве внешнего ключа.

Тогда у меня есть информация с курсами продаж (таблица RATESELLINGINFO), основанная на определенной RATECARD, а также информация о пункте назначения вместе с информацией о транке, все из которых отслеживаются в таблице RATEBUYINGINFO (и нет, я не вижу укажем выделение DESTINATION в качестве отдельной таблицы, поскольку разные соединительные линии разных провайдеров не предоставляют уникальных имен назначения), поэтому у меня есть внешние ключи RateCardID и RateBuyingInfoID в качестве внешних ключей в таблице RATESELLINGINFO.

Теперь проблема заключается в том, что через эти два внешних ключа последняя таблица имеет доступ к двум значениям TrunkID (одно в RATECARD и одно в RATEBUYINGINFO), которые всегда должны быть одинаковыми (очевидно, один курс продажи относится к одной магистрали), но архитектура базы данных никоим образом не гарантирует этого. Есть ли элегантное решение этой проблемы?

1 Ответ

1 голос
/ 30 декабря 2011

Когда вы задаете подобные вопросы, всегда включайте операторы SQL CREATE TABLE и некоторые примеры данных в качестве операторов SQL INSERT. SQL намного надежнее и менее двусмысленен, чем ваши комментарии. (Вы можете отредактировать свой вопрос и добавить этот материал сейчас, чтобы получить лучшие ответы от людей, которые читают это позже.)

Идентификатор транка в обеих таблицах RATECARD и RATEBUYINGINFO, вероятно, должен быть частью первичного ключа или частью уникального ограничения в обеих этих таблицах. Если это так, то вы можете один раз сохранить идентификатор транка в RATESELLINGINFO с перекрывающимися ограничениями внешнего ключа. Что-то вроде 

...
foreign key (trunk_id, rate_card_id) 
  references ratecard (trunk_id, rate_card_id),
foreign key (trunk_id, rate_buying_info_id)
  references rate_buying_info (trunk_id, rate_buying_info_id)
...

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

Дополнительный совет: отбросьте слово «информация» из названия вашей таблицы. Все таблицы содержат информацию; добавив, что к названию просто шум.

...