Constraints in the physical database are not to be used. The main reason for this is that in a 24/7 environment, they can complicate upgrades and alterations to the database. Any data validations should be handled programmatically instead of leaving the responsibility of data validation on the database.
Referential Integrity should not be implemented in the database. There are a number of advantages to this. Firstly, in a development environment, not having RI implemented means that tables can be dropped and recreated and data loaded and deleted without the overhead of having to get the order of operations correct. In the longer term RI has the effect of slowing up inserts and updates, although the overhead on performance has not yet been quantified.
Primary keys should not have any business meaning and they should only be used to identify each row uniquely in the table.
Ну и как Вам?
[b]"Счастье для всех, даром, и пусть никто не уйдет обиженный!"[/b]
[i]А. и Б. Стругацкие, "Пикник на обочине"[/i]
Primary keys should not have any business meaning and they should only be used to identify each row uniquely in the table.
Ну и как Вам?
I think this is someone trying to be funny, right ?
The last paragraph is not so clear-cut though: you can use surrogates but only when there are no natural identifiers, or there are composite keys which substantially degrade performance and complicate referential integrity.
Я бы согласился, если мы говорим про Data Warehouse и боремся за время. Был опыт, когда 5 часов (разница по времени между Восточным побережьем и Гавайями) не хватало, чтобы залить данные и обработать их (ну очень много их было). Тогда пошли именно по этому пути - дропнули FK constraints, check constraints, чтобы ETL тулза работала побыстрее.
Для всего остального - OLTP, batch processing - это не подходит.
Если рассматривать причины неиспользования FK, check constraints, указанные в цитате,то бред полнейший.
Lazy44 wrote:Я бы согласился, если мы говорим про Data Warehouse и боремся за время. Был опыт, когда 5 часов (разница по времени между Восточным побережьем и Гавайями) не хватало, чтобы залить данные и обработать их (ну очень много их было). Тогда пошли именно по этому пути - дропнули FK constraints, check constraints, чтобы ETL тулза работала побыстрее.
Ну необязательно так. Если боремся за скорость в инсертах то обычно это пару таблиц. Достаточно временно деактивировать ФК. Или я не прав?
А почему бы и нет. Главное все не отдавать на клиентскую сторону.
Т.е. чтобы клиент чистый SQL мог выполнять только в виде SELECT, а INSERT, UPDATE и DELETE делался с помощью stored procedures.
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
Ну если логика энфорсится в stored procedure То дублировать проверки в FK избыточно
Я меня был опыт очень большого проекта с порядка 500 тали и около 14000 stored proc, гденет ни одного FK
Вся логика в процедурах
Однако вообще от утверждения веет такой категоричностью что работать под этим менеджером я бы не хотел
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Первые два бред, хотя допускаю случаи, когда приходится жертвовать FK & RI во имя быстродействия (у нас было раз подобное, когда приходилось заливать много данных, но вышли из положения удаляя и восстанавливая индксы и FK после процесса).
Третий же пункт я обеими руками "за". PK только artificial, со временем жизни равным времени жизни записи. Распространенное исключение - many-2-many таблица, в которой PK - пара ключей из связки.
IA72 wrote: Первые два бред, хотя допускаю случаи, когда приходится жертвовать FK & RI во имя быстродействия (у нас было раз подобное, когда приходилось заливать много данных, но вышли из положения удаляя и восстанавливая индксы и FK после процесса).
Это абсолютно нормальная ситуация - когда точно знаешь, что делаешь. Но как минимум при такой операции TABLE EXCLUSIVE LOCK!
IA72 wrote: Третий же пункт я обеими руками "за". PK только artificial, со временем жизни равным времени жизни записи. Распространенное исключение - many-2-many таблица, в которой PK - пара ключей из связки.
Location: SPB --> Gloucester, MA, US --> SPB --> Paris
Postby Dmitry67 »
JustMax wrote:
IA72 wrote: Первые два бред, хотя допускаю случаи, когда приходится жертвовать FK & RI во имя быстродействия (у нас было раз подобное, когда приходилось заливать много данных, но вышли из положения удаляя и восстанавливая индксы и FK после процесса).
Это абсолютно нормальная ситуация - когда точно знаешь, что делаешь. Но как минимум при такой операции TABLE EXCLUSIVE LOCK!
Вы наверное про FK без индекса ?
Но тут же по то что времено убирается то и то
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
