Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Столько времени занимаюсь базами данных, а понятия не имею что такое ON UPDATE CASCADE, хотя... дайте подумать.... А! Мазь от геморроя! Только зачем мне мазь? И геморрой мне ни к чему. Ну его этот геморрой, буду пользоваться старым дедовским способом: только суррогатные ключи, еще ни разу не подводили меня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 10:59 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
А вот интересный вопрос по поводу: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 11:08 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
goodronА вот интересный вопрос по поводу: не то нажал... Так вот вопрос: Какие могут возникнуть аномалии или просто какие минусы при использовании суррогатных ключей? Я за свой пока еще небольшой опыт ни разу не пожалел, что практически всегда использовал autoincrement (indentity). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 11:11 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
У меня даже выдумать аномалию по этому поводу не получается -------------------- Не учи отца и баста! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 11:13 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Old NickУ меня даже выдумать аномалию по этому поводу не получается И я тоже представить не могу... Ежели только место дополнительное эти ключи занимают - так и ладно... Может чего со скоростью происходит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 11:27 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
SarinКстати про суррогатные ключи. Они автоматом позволяют привести базу после к 3НФ к НФБК. И вообще нормализацию упрощают сильно. Это все равно, что выключать свет зажмуривая глаза:). Ограничения целостности (которые и выражаются естественными ключами) кто отслеживать будет? Никто - тогда правильней говорить "без ограничений целостности жить автоматом легче". Сохраняем бизнес-правила - тогда суррогатные ключи добавляются к естественным, а не заменяют их. Old NickУ меня даже выдумать аномалию по этому поводу не получается -------------------- Не учи отца и баста! С закрытыми-то глазами :). Пример ограничения "Тот же", требующего идентифицирующей миграции (ИМ) ключа (Не совсем в тему - идентифицирующая миграция может быть и суррогата, но когда применяют СК, как правило НЕ применяют ИМ, так что где-то рядом с темой): Таблицы: СТРАНА, РЕГИОН, ПАРТНЕРСТВО . Связи: РЕГИОН >-находится в -- СТРАНА ПАРТНЕРСТВО >-включает участник1 -- РЕГИОН ПАРТНЕРСТВО >-включает участник2 -- РЕГИОН Бизнес-правило: Регионы-партнеры должны находится в одной стране. Если ключ СТРАНА мигрирует в ключ РЕГИОН, то внешние ключи участник1 и участник2 на автомате могут поддерживать бизнес-правило. Если нет - пишем проверку ручками... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 12:44 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Бизнес-правило нельзя зашивать в код, вернее даже в структуру базы. Это всегда пользовательская фича и она может меняться, поэтому в данном случае я бы сделал бизнес-правило в виде процедуры-обработчика, подвешенной к событию (уж какое это событие, определить по вкусу). Действует бизнес-правило - вызывается обработчик, перестало действовать - отключили. Причем отключил пользователь из пользовательского интерфейса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 13:50 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
> Таблицы: СТРАНА, РЕГИОН, ПАРТНЕРСТВО . Кто Вас научил так проектировать? > Регионы-партнеры должны находится в одной стране. Кто Вам сказал, что это бизнес-правило? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 14:21 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
> Бизнес-правило нельзя зашивать в код, вернее даже в структуру базы. Сегодня, похоже, день откровений. Кто Вам сказал такую чушь? Автора - в студию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 14:23 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Бизнес-правило в виде структуры базы данных? При смене бизнес-правила будем менять структуру? Зае...шибись. Вот так и появляются различные SAPы и AXAPTы с кучей программистов, обслуживающих их в виде клепания новых и переделывания старых процедур, а также добавления полей и таблиц при любом изменении требований. Даже когда НДС меняется с 20 на 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 15:00 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Old NickСтолько времени занимаюсь базами данных, а понятия не имею что такое ON UPDATE CASCADE Это такая опция к ограничению ссылочной целостности, которая при обновлении первичного ключа каскадно обновляет внешние ключи у подчиненных полей. Цитаты из "Data Definition Guide" и "Language Reference". СУБД -- InterBase 6. <tconstraint> = [CONSTRAINT constraint] FOREIGN KEY ( col [, col …]) REFERENCES other_table [ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] Referential integrity checks are available in the form of the ON UPDATE and ON DELETE options to the REFERENCES statement. When you create a foreign key by defining a column or table REFERENCES constraint, you can specify what should happen to the foreign key when the referenced primary key changes. The options are: NO ACTION [Default]: The foreign key does not change (can cause the primary key update or delete to fail due to referential integrity checks); CASCADE The corresponding foreign key is updated or deleted as appropriate to the new value of the primary key; SET DEFAULT Every column of the corresponding foreign key is set to its default value; fails if the default value of the foreign key is not found in the primary key; SET NULL Every column of the corresponding foreign key is set to NULL. If you do not use the ON UPDATE and ON DELETE options when defining foreign keys, you must make sure that when information changes in one place, it changes in all referencing columns as well. Typically, you write triggers to do this. CREATE TABLE PROJECT ( . . . TEAM_LEADER INTEGER REFERENCES EMPLOYEE (EMP_NO) ON DELETE SET NULL ON UPDATE CASCADE . . .); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 15:25 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
авторЭто такая опция к ограничению ссылочной да с этим никто не спорит. Просто оцените стоимость апдейта, если ваш пк входит скажем в ~10**5 записей различных детей. А если еще и злоупотребляете вхождением его (на стороне связанных записей) в составные ключи/индексы (которые видимо придется перестраивать)? Что должны делать другие ползатели в моменты блокировки массы записей в связанных таблицах (даже версионник, мне кажется, не пишет в изменяемую запись?). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 15:53 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Не было печали, черти накачали. Может я упустил в этой жизни что-то. Живу и не знаю что можно ключ менять. Насколько лучше я бы жил если бы раньше знал про это. Менял бы их по нескольку раз на день. А то ведь и в голову такая мысля ни разу не пришла. Чувствую себя теперь ущербным :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 16:04 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Вопрос, Old Nick, был про автора. Вы его назовете? > Бизнес-правило в виде структуры базы данных? Именно в виде структуры данных. > При смене бизнес-правила будем менять структуру? Нет, структуру данных менять не будем. Будем менять описание бизнес-правила. Где проблема? > Вот так и появляются различные SAPы и AXAPTы с кучей программистов, А дерьмо заключается в том, что альтернатива sap'ам и axapta'м - $%^ поделки вместо нормальных приложений. 2 Владимир П. > Цитаты из "Data Definition Guide" и "Language Reference". СУБД -- InterBase 6. Да, знать о cascade update/delete нужно. Использовать - нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 17:01 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
У меня к коллегам есть вопрос. Предположим у нас имеется 3 таблицы. 1) Customer (customer_id,....) 2) Organization (org_id,...) 3) Person (person_id,....) Т.е. между Customer и Person, ровно как и между Customer и Organization существует связь IS A . В терминах ООП Organization и Person - подтипы Customer. Задача - реализоватьтолько на констрэйнтах (без использования триггеров и хп) правило: Если существует Person с Person_id равным N, то существует Customer c Сustomer_id равным N и не может существовать Organization с org_id равным N. и наоборот. Т.е. множества значений org_id и customer_id не должны пересекаться. )) Очень хочу чтобы кто-нибудь показал, как это сделать на суррогатных ключах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 18:39 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
> Если существует Person с Person_id равным N, то существует Customer c > Сustomer_id равным N и не может существовать Organization с org_id равным N. > и наоборот. > Т.е. множества значений org_id и customer_id не должны пересекаться. Сформулируйте _начальную задачу_, а не Ваш вариант реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 18:46 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
> Сформулируйте _начальную задачу_, а не Ваш вариант реализации Ну вы опять за свое. Так не честно. Если не можем решить задачу, то давайте ее поменяем что-ли? Еще раз другими словами: Хочу чтоб всегда, если клиент является, например, физ.лицом, то для него всегда существовали записи только в customer и person. B чтоб никогда, ни при каких обстоятельствах (кривые руки программера, ошибка оператора и пр.) не появилась записть у таблице Organization!... То же самое и о таблице Organization. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 18:58 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
> Ну вы опять за свое. Так не честно. Если не можем решить задачу, то давайте ее поменяем что-ли? Не, все не так. Вы сформулируйте начальную задачу: что хотите регистрировать и для какой цели. Над задачей можно подумать. А думать над конкретной реализацией - нет смысла. Объясню, почему в данном случае нет смысла: Вы хотите использовать imho абсолютно противоестественное ограничение при наличии работоспособных альтернативных вариантов. Почему - ну, видимо, посчитали, что так лучше. ОК, Ваше решение - это Ваше решение и Ваша головная боль. Как описывать физические и юридические лица - здесь обсуждалось миллион раз. ;) Для Вашей реализации могу предложить Вам такие костыли: используйте только четные/нечетные значения суррогатных ключей для физических/юридических лиц. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 19:17 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Для Вашей реализации могу предложить Вам такие костыли: используйте только четные/нечетные значения суррогатных ключей для физических/юридических лиц. ;) Уважаемый guest_20040621! вы хитры, изворотливы, находчивы. Ценю. Я не люблю вдаваться в конкретные задачи, потому как считаю более важным найти принцип (шаблон) для решения таких задач. А если задача станет еще сложнее? например у нас будет один клас и целое дерево подклассов со своими атрибутами (не забываем о наследовани атрибутов, но однако полагаем что множественное наследование у нас отсутствует). И, как же по вашему в этом случае добиться целостности? Чтобы всякий объект (представленный несколькими записями в иерархии таблиц) случайным образом не был наделен ненужными ему свойствами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 19:27 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
> Я не люблю вдаваться в конкретные задачи, потому как считаю более важным найти принцип (шаблон) > для решения таких задач. Я и просил сформулировать задачу целиком. ;) > А если задача станет еще сложнее? например у нас будет один клас и целое дерево подклассов со своими атрибутами (не > забываем о наследовани атрибутов, но однако полагаем что множественное наследование у нас отсутствует). Давайте уже оставим в покое наследование и ограничимся реляционными структурами. Из них сделать объекты, полагаю, труда не составит. Иначе все будет как всегда. :( Обсуждаемая задача традиционным образом imho не решается (точнее, решается, но настолько криво, что об этом и говорить не хочется). Из альтернативных вариантов imho наиболее предпочтительным является решение на основе метаданных. > случайным образом не был наделен ненужными ему свойствами? Constraint в виде таблицы связи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 19:55 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
goodron Old NickУ меня даже выдумать аномалию по этому поводу не получается И я тоже представить не могу... Ежели только место дополнительное эти ключи занимают - так и ладно... Может чего со скоростью происходит?Аномалия? А пожалте. Вот у нас есть таблица персон с суррогатным ключом. И сегодня мы видим, что под записью с ID = 1234 скрывается Петров, паспорт 98 76 543210. Приходим на работу завтра - и что видим: те документы, которые оформлял Петров теперь вроде как оформлял Васечкин, паспорт 67 89 452301! Объяснение оператора: "Ну и что: раз атрибуты можно менять, мы их и поменяли. А что, нельзя было? 8-[ ] Это я к тому, что без дополнительных мероприятий СК не могут обеспечить целостность во времени. А ЕК - могут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2005, 23:28 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Романыч, есть разница между "теоритечиской" нормализацией и "практической". То, что Вы нарисовали разумно с точки зрения теории и логической модели. При физической имплементации имеет существенный смысл перейти на суррогатные ключи. Т.е. по делу вы оба правы, но если говорить о практической имплементации то второй товарищь прав. Помнити радикализм в дизайне ни к чему хорошему не приводит, все выражается из стоимости и что Вы за это получили. В качестве дипломной работы я бы пошел с сурогатными ключами и сказал бы что ключи данные выбраны для минимизации таких то оверхедов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 03:13 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
Вот товарища Urri в данном вопросе целиком и полностью поддерживаю. И вообще, почитав весь бред про суррогатные ключи, про то какие они замечательные я начинаю понимать почему практически все системы криво работают. Видел я таких проектировщиков. Всю модель разрабатывает за пол часа. Типа - создаёт таблицу. Связь с другой должна быть 0-1. Делает на этой таблице свой собственный суррогатный ключ, естесс-но identity. Зачем?... На него ж ни одна таблица ссылаться не будет! но все равно делает. А потом в такой модели несколько предприятий с одним INN, и всякая другая хрень и сплошной геморрой с получением отчетности. Господа! ПК предназначен не только для того, чтобы уникально и однозначно идентифицировать запись. Но и для того, чтобы поддерживать определенные бизнес правила. 2 guest_20040621 Приведенная задача решается традиционнным способом, если использовать составной первичный плюч по таблице Customer. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 10:14 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
gardenman wrote: >Аномалия? А пожалте. >Вот у нас есть таблица персон с суррогатным ключом. И сегодня мы видим, >что под записью с ID = 1234 скрывается Петров, паспорт 98 76 543210. >Приходим на работу завтра - и что видим: те документы, которые оформлял >Петров теперь вроде как оформлял Васечкин, паспорт 67 89 452301! >Объяснение оператора: "Ну и что: раз атрибуты можно менять, мы их и >поменяли. А что, нельзя было? 8-[ ] >Это я к тому, что без дополнительных мероприятий СК не могут обеспечить >целостность во времени. А ЕК - могут. Дык и из окна можно прыгать, но не прыгает ведь? ну, про персоны ваще без паспорта кто нить слышал? а когда персона паспорт меняет? тоже слышали? и как прикажете поступить? > Вот товарища Urri в данном вопросе целиком и полностью поддерживаю. > И вообще, почитав весь бред про суррогатные ключи, про то какие они > замечательные я начинаю понимать почему практически все системы криво > работают. вах! пачти все и пачти криво! Бред, говорите... серебряную пулю ищем... > Видел я таких проектировщиков. Всю модель разрабатывает за пол часа. > Типа - создаёт таблицу. Связь с другой должна быть 0-1. Делает на этой > таблице свой собственный суррогатный ключ, естесс-но identity. Зачем?... > На него ж ни одна таблица ссылаться не будет! но все равно делает. А > потом в такой модели несколько предприятий с одним INN, и всякая другая > хрень и сплошной геморрой с получением отчетности. Гы.... несколько предприятий с одним ИНН... ага, к примеру - филиалы. Бывает такое.... И ваще, если у меня ЕК состоит из 8 полей, я что, должен писать нечто вроде Код: plaintext 1. Код: plaintext 1. > > > Господа! ПК предназначен не только для того, чтобы уникально и > однозначно идентифицировать запись. Но и для того, чтобы поддерживать > определенные бизнес правила. Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 10:28 |
|
||
|
Объясните кто прав: студент или человек с опытом?
|
|||
|---|---|---|---|
|
#18+
> почитав весь бред про суррогатные ключи, про то какие они замечательные Дружище, Вы считаете нормальным публично демонстрировать свое невежество? > ПК предназначен не только для того, чтобы уникально и однозначно идентифицировать запись. > Но и для того, чтобы поддерживать определенные бизнес правила. Кролики - это не только ценный мех, но и 2 - 3 килограмма ценного диетического мяса. Хватит нести чушь. > Приведенная задача решается традиционнным способом, если использовать составной первичный плюч > по таблице Customer. Вы условие задачи внимательно читали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.08.2005, 10:32 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33198454&tid=1545723]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
40ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 252ms |
| total: | 393ms |

| 0 / 0 |
