powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объясните кто прав: студент или человек с опытом?
25 сообщений из 82, страница 2 из 4
Объясните кто прав: студент или человек с опытом?
    #33198454
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Столько времени занимаюсь базами данных, а понятия не имею что такое ON UPDATE CASCADE, хотя... дайте подумать.... А! Мазь от геморроя! Только зачем мне мазь? И геморрой мне ни к чему. Ну его этот геморрой, буду пользоваться старым дедовским способом: только суррогатные ключи, еще ни разу не подводили меня.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33198488
goodron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А вот интересный вопрос по поводу:
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33198496
goodron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
goodronА вот интересный вопрос по поводу:
не то нажал...
Так вот вопрос:
Какие могут возникнуть аномалии или просто какие минусы при использовании суррогатных ключей? Я за свой пока еще небольшой опыт ни разу не пожалел, что практически всегда использовал autoincrement (indentity).
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33198503
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня даже выдумать аномалию по этому поводу не получается

--------------------
Не учи отца и баста!
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33198570
goodron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old NickУ меня даже выдумать аномалию по этому поводу не получается
И я тоже представить не могу...
Ежели только место дополнительное эти ключи занимают - так и ладно...
Может чего со скоростью происходит?
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33198858
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SarinКстати про суррогатные ключи.

Они автоматом позволяют привести базу после к 3НФ к НФБК.
И вообще нормализацию упрощают сильно.
Это все равно, что выключать свет зажмуривая глаза:).
Ограничения целостности (которые и выражаются естественными ключами) кто отслеживать будет? Никто - тогда правильней говорить "без ограничений целостности жить автоматом легче".
Сохраняем бизнес-правила - тогда суррогатные ключи добавляются к естественным, а не заменяют их. Old NickУ меня даже выдумать аномалию по этому поводу не получается

--------------------
Не учи отца и баста!
С закрытыми-то глазами :).
Пример ограничения "Тот же", требующего идентифицирующей миграции (ИМ) ключа (Не совсем в тему - идентифицирующая миграция может быть и суррогата, но когда применяют СК, как правило НЕ применяют ИМ, так что где-то рядом с темой):

Таблицы: СТРАНА, РЕГИОН, ПАРТНЕРСТВО .

Связи:
РЕГИОН >-находится в -- СТРАНА
ПАРТНЕРСТВО >-включает участник1 -- РЕГИОН
ПАРТНЕРСТВО >-включает участник2 -- РЕГИОН

Бизнес-правило:
Регионы-партнеры должны находится в одной стране.

Если ключ СТРАНА мигрирует в ключ РЕГИОН, то внешние ключи участник1 и участник2 на автомате могут поддерживать бизнес-правило. Если нет - пишем проверку ручками...
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199112
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бизнес-правило нельзя зашивать в код, вернее даже в структуру базы. Это всегда пользовательская фича и она может меняться, поэтому в данном случае я бы сделал бизнес-правило в виде процедуры-обработчика, подвешенной к событию (уж какое это событие, определить по вкусу).
Действует бизнес-правило - вызывается обработчик, перестало действовать - отключили. Причем отключил пользователь из пользовательского интерфейса.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199239
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Таблицы: СТРАНА, РЕГИОН, ПАРТНЕРСТВО .

Кто Вас научил так проектировать?

> Регионы-партнеры должны находится в одной стране.

Кто Вам сказал, что это бизнес-правило?
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199252
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Бизнес-правило нельзя зашивать в код, вернее даже в структуру базы.

Сегодня, похоже, день откровений. Кто Вам сказал такую чушь? Автора - в студию.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199410
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Бизнес-правило в виде структуры базы данных? При смене бизнес-правила будем менять структуру? Зае...шибись.

Вот так и появляются различные SAPы и AXAPTы с кучей программистов, обслуживающих их в виде клепания новых и переделывания старых процедур, а также добавления полей и таблиц при любом изменении требований. Даже когда НДС меняется с 20 на 18.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199518
Фотография Владимир П.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
. . .);
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199618
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЭто такая опция к ограничению ссылочной
да с этим никто не спорит. Просто оцените стоимость апдейта, если ваш пк входит скажем в ~10**5 записей различных детей. А если еще и злоупотребляете вхождением его (на стороне связанных записей) в составные ключи/индексы (которые видимо придется перестраивать)? Что должны делать другие ползатели в моменты блокировки массы записей в связанных таблицах (даже версионник, мне кажется, не пишет в изменяемую запись?).
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199656
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не было печали, черти накачали.

Может я упустил в этой жизни что-то. Живу и не знаю что можно ключ менять. Насколько лучше я бы жил если бы раньше знал про это. Менял бы их по нескольку раз на день. А то ведь и в голову такая мысля ни разу не пришла. Чувствую себя теперь ущербным :-(
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33199903
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вопрос, Old Nick, был про автора. Вы его назовете?

> Бизнес-правило в виде структуры базы данных?

Именно в виде структуры данных.

> При смене бизнес-правила будем менять структуру?

Нет, структуру данных менять не будем. Будем менять описание бизнес-правила. Где проблема?

> Вот так и появляются различные SAPы и AXAPTы с кучей программистов,

А дерьмо заключается в том, что альтернатива sap'ам и axapta'м - $%^ поделки вместо нормальных приложений.

2 Владимир П.

> Цитаты из "Data Definition Guide" и "Language Reference". СУБД -- InterBase 6.

Да, знать о cascade update/delete нужно. Использовать - нет.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200245
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня к коллегам есть вопрос. Предположим у нас имеется 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 не должны пересекаться.
)) Очень хочу чтобы кто-нибудь показал, как это сделать на суррогатных ключах.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200261
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Если существует Person с Person_id равным N, то существует Customer c
> Сustomer_id равным N и не может существовать Organization с org_id равным N.
> и наоборот.
> Т.е. множества значений org_id и customer_id не должны пересекаться.

Сформулируйте _начальную задачу_, а не Ваш вариант реализации.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200299
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Сформулируйте _начальную задачу_, а не Ваш вариант реализации
Ну вы опять за свое. Так не честно. Если не можем решить задачу, то давайте ее поменяем что-ли?
Еще раз другими словами:
Хочу чтоб всегда, если клиент является, например, физ.лицом, то для него всегда существовали записи только в customer и person. B чтоб никогда, ни при каких обстоятельствах (кривые руки программера, ошибка оператора и пр.) не появилась записть у таблице Organization!...
То же самое и о таблице Organization.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200337
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Ну вы опять за свое. Так не честно. Если не можем решить задачу, то давайте ее поменяем что-ли?

Не, все не так. Вы сформулируйте начальную задачу: что хотите регистрировать и для какой цели. Над задачей можно подумать. А думать над конкретной реализацией - нет смысла. Объясню, почему в данном случае нет смысла: Вы хотите использовать imho абсолютно противоестественное ограничение при наличии работоспособных альтернативных вариантов. Почему - ну, видимо, посчитали, что так лучше. ОК, Ваше решение - это Ваше решение и Ваша головная боль. Как описывать физические и юридические лица - здесь обсуждалось миллион раз. ;)

Для Вашей реализации могу предложить Вам такие костыли: используйте только четные/нечетные значения суррогатных ключей для физических/юридических лиц. ;)
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200351
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621>
Для Вашей реализации могу предложить Вам такие костыли: используйте только четные/нечетные значения суррогатных ключей для физических/юридических лиц. ;)

Уважаемый guest_20040621! вы хитры, изворотливы, находчивы. Ценю.
Я не люблю вдаваться в конкретные задачи, потому как считаю более важным найти принцип (шаблон) для решения таких задач.

А если задача станет еще сложнее? например у нас будет один клас и целое дерево подклассов со своими атрибутами (не забываем о наследовани атрибутов, но однако полагаем что множественное наследование у нас отсутствует). И, как же по вашему в этом случае добиться целостности? Чтобы всякий объект (представленный несколькими записями в иерархии таблиц) случайным образом не был наделен ненужными ему свойствами?
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200385
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Я не люблю вдаваться в конкретные задачи, потому как считаю более важным найти принцип (шаблон)
> для решения таких задач.

Я и просил сформулировать задачу целиком. ;)

> А если задача станет еще сложнее? например у нас будет один клас и целое дерево подклассов со своими атрибутами (не
> забываем о наследовани атрибутов, но однако полагаем что множественное наследование у нас отсутствует).

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

Обсуждаемая задача традиционным образом imho не решается (точнее, решается, но настолько криво, что об этом и говорить не хочется). Из альтернативных вариантов imho наиболее предпочтительным является решение на основе метаданных.

> случайным образом не был наделен ненужными ему свойствами?

Constraint в виде таблицы связи.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200541
Urri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
goodron Old NickУ меня даже выдумать аномалию по этому поводу не получается
И я тоже представить не могу...
Ежели только место дополнительное эти ключи занимают - так и ладно...
Может чего со скоростью происходит?Аномалия? А пожалте.
Вот у нас есть таблица персон с суррогатным ключом. И сегодня мы видим, что под записью с ID = 1234 скрывается Петров, паспорт 98 76 543210.
Приходим на работу завтра - и что видим: те документы, которые оформлял Петров теперь вроде как оформлял Васечкин, паспорт 67 89 452301! Объяснение оператора: "Ну и что: раз атрибуты можно менять, мы их и поменяли. А что, нельзя было? 8-[ ]
Это я к тому, что без дополнительных мероприятий СК не могут обеспечить целостность во времени. А ЕК - могут.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200612
папа Карло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Романыч, есть разница между "теоритечиской" нормализацией и "практической". То, что Вы нарисовали разумно с точки зрения теории и логической модели. При физической имплементации имеет существенный смысл перейти на суррогатные ключи. Т.е. по делу вы оба правы, но если говорить о практической имплементации то второй товарищь прав. Помнити радикализм в дизайне ни к чему хорошему не приводит, все выражается из стоимости и что Вы за это получили. В качестве дипломной работы я бы пошел с сурогатными ключами и сказал бы что ключи данные выбраны для минимизации таких то оверхедов.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200880
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот товарища Urri в данном вопросе целиком и полностью поддерживаю.
И вообще, почитав весь бред про суррогатные ключи, про то какие они замечательные я начинаю понимать почему практически все системы криво работают.
Видел я таких проектировщиков. Всю модель разрабатывает за пол часа. Типа - создаёт таблицу. Связь с другой должна быть 0-1. Делает на этой таблице свой собственный суррогатный ключ, естесс-но identity. Зачем?... На него ж ни одна таблица ссылаться не будет! но все равно делает. А потом в такой модели несколько предприятий с одним INN, и всякая другая хрень и сплошной геморрой с получением отчетности.


Господа! ПК предназначен не только для того, чтобы уникально и однозначно идентифицировать запись. Но и для того, чтобы поддерживать определенные бизнес правила.

2 guest_20040621
Приведенная задача решается традиционнным способом, если использовать составной первичный плюч по таблице Customer.
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200918
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman wrote:
>Аномалия? А пожалте.
>Вот у нас есть таблица персон с суррогатным ключом. И сегодня мы
видим, >что под записью с ID = 1234 скрывается Петров, паспорт 98 76 543210.
>Приходим на работу завтра - и что видим: те документы, которые
оформлял >Петров теперь вроде как оформлял Васечкин, паспорт 67 89
452301! >Объяснение оператора: "Ну и что: раз атрибуты можно менять, мы
их и >поменяли. А что, нельзя было? 8-[ ]
>Это я к тому, что без дополнительных мероприятий СК не могут
обеспечить >целостность во времени. А ЕК - могут.
Дык и из окна можно прыгать, но не прыгает ведь?
ну, про персоны ваще без паспорта кто нить слышал? а когда персона
паспорт меняет? тоже слышали? и как прикажете поступить?

> Вот товарища Urri в данном вопросе целиком и полностью поддерживаю.
> И вообще, почитав весь бред про суррогатные ключи, про то какие они
> замечательные я начинаю понимать почему практически все системы криво
> работают.
вах! пачти все и пачти криво!
Бред, говорите... серебряную пулю ищем...

> Видел я таких проектировщиков. Всю модель разрабатывает за пол часа.
> Типа - создаёт таблицу. Связь с другой должна быть 0-1. Делает на этой
> таблице свой собственный суррогатный ключ, естесс-но identity. Зачем?...
> На него ж ни одна таблица ссылаться не будет! но все равно делает. А
> потом в такой модели несколько предприятий с одним INN, и всякая другая
> хрень и сплошной геморрой с получением отчетности.
Гы.... несколько предприятий с одним ИНН... ага, к примеру - филиалы.
Бывает такое....
И ваще, если у меня ЕК состоит из 8 полей, я что, должен писать нечто вроде
Код: plaintext
1.
delete dbo.Table where Field1=@field1 and ... and Field8=@Field8
мне проще
Код: plaintext
1.
delete dbo.Table where id = @id
чисто технологически проще.
>
>
> Господа! ПК предназначен не только для того, чтобы уникально и
> однозначно идентифицировать запись. Но и для того, чтобы поддерживать
> определенные бизнес правила.
Posted via ActualForum NNTP Server 1.2
...
Рейтинг: 0 / 0
Объясните кто прав: студент или человек с опытом?
    #33200927
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> почитав весь бред про суррогатные ключи, про то какие они замечательные

Дружище, Вы считаете нормальным публично демонстрировать свое невежество?

> ПК предназначен не только для того, чтобы уникально и однозначно идентифицировать запись.
> Но и для того, чтобы поддерживать определенные бизнес правила.

Кролики - это не только ценный мех, но и 2 - 3 килограмма ценного диетического мяса. Хватит нести чушь.

> Приведенная задача решается традиционнным способом, если использовать составной первичный плюч
> по таблице Customer.

Вы условие задачи внимательно читали?
...
Рейтинг: 0 / 0
25 сообщений из 82, страница 2 из 4
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объясните кто прав: студент или человек с опытом?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]