Как бороться с «я» отношения в SQL? - PullRequest
Новая
       55

Как бороться с «я» отношения в SQL?

0 голосов
/ 27 сентября 2019

В нашем приложении у нас есть clients, и у каждого клиента есть список customers

client table:
id  |  name
-------------
1   |  happy
2   |  bashful


customer table:
id  | client_id  |  name
----------------------------------------
50  | 1          | happys first customer
51  | 1          | happys second customer
52  | 2          | bashfuls first customer

. Не вдаваясь в подробности, у каждого клиента будет список применимых цен.им.Для простоты мы скажем, что у нас также есть таблица продуктов с идентификаторами продуктов 1,2 и 3, и у каждого покупателя будет уникальная цена для каждого товара.Таким образом, у клиента 50 будет 3 строки, у клиента 51 будет 3 строки, а у клиента 52 будет 3 строки в этой price таблице. 

price table:
id  | customer_id  |  product_id  |
----------------------------------------
50  | 50           | 1            |  4.99
51  | 50           | 2            |  6.20
52  | 50           | 3            |  8.00
...

Теперь вот кикер: каждый клиент должен такжеУ есть свои строки в этой таблице price.Мы будем называть этот прайс-лист клиента «базовым списком», поскольку в контексте приложения сравниваются все цены клиентов.

Существует три сразу очевидных решенияя, но я не уверен, что кто-то из них прав, или какой из них оптимален:

Решение 1

Добавьте строку в таблицу клиентов, где имя будет выглядеть как «Я».', так что' self 'может рассматриваться почти как клиент

.

Решение 2

Сделать таблицу цен двумя столбцами внешнего ключа, один с customer_id и одинс client_id, и разрешить customer_id быть нулевым - если customer_id равен null, я знаю, что строка является строкой клиента.

.

Решение 3

Имеет 2 таблицы ценкоторые в основном идентичны: один для внешнего ключа для клиентов и один для внешнего ключа для клиентов.

1 Ответ

0 голосов
/ 27 сентября 2019

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

Вы не указали, являются ли клиенты уникальными для клиентов, поэтому позвольте мне предположить, что онине.

Это говорит о том, что варианты 2 и 3 являются наиболее разумными.На самом деле их мало, чтобы их разделить.С одной таблицей вы хотите проверить ограничение, чтобы был установлен ровно один из идентификаторов - если только у вас нет клиентов, совместно используемых клиентами и , вы разрешаете специфичные для клиента, специфичные для клиента, и специфичные для клиента и клиента цены.

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

...