Мне нужно иметь возможность запрашивать в БД значения, введенные определенным поставщиком, чтобы я мог предложить их в качестве параметров.Так или иначе, данные должны быть связаны с поставщиком.
Это довольно распространенная проблема, которую необходимо решить в различных областях, где несколько клиентов вносят вклад в общую структуру базы данных, но не хотят видетьданные друг друга.В Oracle, например, есть нечто, называемое виртуальной частной базой данных.По сути, столбец добавляется в каждую таблицу, и значение в столбце для данной строки указывает, кто «владеет» строкой.Представления могут быть основаны на этом:
CUSTOMERA : create view CUSTOMERAPRODUCTS as select * from products where products.user='CUSTOMERA'
CUSTOMERB: create view CUSTOMERBPRODUCTS as select * from products where products.user='CUSTOMERB'
Вы создаете составные ключи (первичные, внешние и альтернативные уникальные) как этот [псевдосинтаксис]:
Table: COLORS
vendorid INT
colorid INT
color varchar(20)
PK = (vendorid, colorid)
UNIQUE index on (vendorid, color)
Table: PRODUCTS
vendorid INT
productid INT
product varchar(20)
PK = (vendorid, productid)
UNIQUE index on (vendorid, product)
Table: PRODUCTCOLORS
vendorid INT
productid INT
colorid INT
PK = (vendorid, productid)
UNIQUE index on (vendorid, color)
FK (vendorid, productid) references PRODUCTS(vendorid, productid)
FK (vendorid, colorid) references COLORS(vendorid, colorid)
Теперь, однако,если вы также хотите сделать это конкретное правило (и аналогичное ему) обязательным требованием:
Color values must be unique not only within the individual vendor's subset
but unique system-wide (e.g. so that there is only one row containing 'Emerald Green')
Вы должны сделать это в таблице COLORS:
UNIQUE index on (color)
Однако это помешаетпоставщик B не добавил «Изумрудно-зеленый» в таблицу COLORS для использования со своими продуктами, если этот конкретный цвет уже существовал в таблице, однако поставщик B не смог увидеть этот цвет, поскольку эта строка будет отфильтрована из их представлений, если «виртуальный закрытый»база данных »или какой-то аналог этого подхода действовал,
Итак, если ваша цель состоит в том, чтобы несколько притоков данных текли в общую реку данных, в которой каждый поставщик может свободно плавать, так сказать, тогдаВы можете столкнуться с беспорядочной ситуацией, которая обычно требует, чтобы таблицы, такие как COLOR и PRODUCTCATEGORY, поддерживались центральным администратором - централизованнопричиной такой ситуации обычно являются данные, которые выглядят следующим образом:
Emerald Green
Emerald-Green
Emmerald Green
, т.е. почти столько же «вариантов», сколько имеется притоков, поэтому ваши уникальные индексы становятся довольно неэффективными.Разве не приятно думать, что они стоят на страже.Вы можете иметь эту проблему вариантов только с одним притоком!Сложно сохранить эти таблицы в здравом уме, добавляя данные только один человек!Чтобы устранить такие помехи, требуется постоянная бдительность со стороны специального администратора данных и гораздо больше дезинфекции пакетного импорта, чем большинство компаний когда-либо готовы участвовать.