Первичный ключ

← →
euru © (2006-04-19 18:12) [320]

> vuk © (19.04.06 17:37) [315]
> Понимаете, обычно пользователи работают со списками документов.
> Обычно на конкретную дату. Отсюда и стоит плясать. А если
> исходить из абстрактной задачи получения номера связанного
> документа по исходному, то решение будет получено не менее
> абстрактное.
Например, в нашей системе ежедневно генерируется 1000-2000 документов. Вы пользователю каждый раз открывать весь этот список и искать в нём нужный документ? Кроме того, конкретная дата может быть разной (сейчас мне понадобились текущие документы, через 5 мин -- недельной давности). Вы предлагаете держать по списку для каждой даты?

> См. выше. Обычно пользователи работают со списками документов.
> Обычно на конкретную дату.
Обычно пользователи работают с дебиторами/кредиторами или со счетами, и документы выбирают для них. А если они хотят посмотреть конкретный документ, то они просто вводят его номер и дату (списки для этого совершенно не нужны).

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

← →
Sergey Masloff (2006-04-19 18:31) [321]

euru © (19.04.06 18:12) [320]
Что-то я не понимаю. А откуда пользователь этот номер возьмет? На память? А 10-значный номер не дольше набрать чем 3 раза мышем тыкнуть?

Про списки. Как правило есть какие-то стандартные варианты типа "мои за даень", "отдела за день" еще пара подобных. На них есть ярлыки то есть условия отбора указывать не надо. Про "ожидание" списка это несерьезно доли секунды он занимает даже для пользователя в трехзвенке на диалапе сидящего.

Вобщем по скорости получается то же а по удобству...
Ну нужно мне посмотреть документы в которых участником было ООО Рога и копыта номер неизвестен но известна примерная сумма и что было это в прошлом месяце вроде бы. И что должен вводить гипотетический юзер?

← →
Lamer@fools.ua © (2006-04-19 18:36) [322]

>>Игорь Шевченко © (19.04.06 16:31) [311]

>Виталий, я же спрашивал конкретно про свой случай, про то, какие преимущества мне дает введение дополнительного объекта в базу данных и механизма его использования вместо того, чтобы явно объявить ссылку на заведомо уникальное поле.
Мы, наверное, просто размышляем по-разному. Для меня данное поле не является заведомо уникальным. Потому что в БД оно пришло извне.

В общем-то, я не пытаюсь кому-то доказать, что СК — серебряная пуля. Просто лично мне приятнее наступать на грабли, связаные с тем, что ПК является СК, а не ЕК.

← →
Jeer © (2006-04-19 18:40) [323]

euru © (19.04.06 18:12) [320]

Понимание Вашей позиции полностью исчезло.
Какие списки ? Это Вы о комбобоксах чт-ли ?
И так можно для небольших справочников.
Для работы же со списками документов - надлежащая форма.
Пользователю предоставляется возможность выборки по условиям, жестким или мягким - это как сделано будет от потребностей.

← →
Игорь Шевченко © (2006-04-19 22:47) [324]

xayam © (19.04.06 17:52) [319]

> вопрос не в этом, а в том кто будет придерживаться этих
> стандартов, а кто нет. И это тоже надо учитывать

Я не понимаю, какое отношение это имеет к типу ключей. Те, кто придерживается, обеспечивает безболезненный обмен данными, не вводя лишних сущностей, а больше, собственно, от задачи ничего не надо.

> Объяснять? Для этого просто добавляется поле с переводом
> на нужный язык

У тебя 100 стран, в которых говорят на разных языках. Будешь заводить 100 полей ? А смысл ?

> Отличить что? СССР вообще нет, это называется избыточность.
> И если они так меняют стандарты, то это как ком, он только
> больше и больше.

Заметь, стандарт не меняется. Была сущность СССР, кодировалась определенным сочетанием. Появилась самостоятельная сущность Россия, для нее выбрано другое сочетание. Никакого изменения стандарта нет.

← →
Игорь Шевченко © (2006-04-19 22:56) [325]

Lamer@fools.ua © (19.04.06 18:36) [322]

> Для меня данное поле не является заведомо уникальным. Потому
> что в БД оно пришло извне.

А во внешнем мире не бывает уникальных значений ? :) На мой взгляд, бывают. Впрочем, до тех пор, пока их, в качестве уникальных, придерживаются те источники, с которыми мне нужно обмениваться данными, меня имеющаяся уникальность устраивает. Ну и заодно, мне не нужно делать дополнительных запросов при импорте, для выяснения того, какой синтетический ключ соответствует пришедшему коду, что на производительности тоже достаточно благотворно сказывается.

Опять же, я свою точку зрения никому не навязываю, просто продолжаю считать, что естественные ключи (или бизнес-ключи, по терминологии автора Keytaxonomy2005) тоже имеют право на существование в структуре базы данных и соображения об их неиспользовании выглядят в большей
степени религиозными, нежели практическими.

С наилучшими,

← →
xayam © (2006-04-19 23:28) [326]

> Игорь Шевченко © (19.04.06 22:47) [324]

> Я не понимаю, какое отношение это имеет к типу ключей.
Как это? Самое прямое. По нашему спору к этому все пришло.

> Те, кто придерживается

...а кто не придерживается беспомощен. Так что ли?

> обеспечивает безболезненный обмен данными

Да кто тебе сказал, что это первостепенная задача?

> не вводя лишних сущностей

сущности, улучшающие структуру (архитектуру, основу - как хочешь назови), не могут быть лишними!

> У тебя 100 стран, в которых говорят на разных языках. Будешь
> заводить 100 полей?

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

> А смысл ?

Очень простой - решить поставленную задачу.

> Заметь, стандарт не меняется. Была сущность СССР, кодировалась
> определенным сочетанием. Появилась самостоятельная сущность
> Россия, для нее выбрано другое сочетание. Никакого изменения
> стандарта нет.

Ты противоречишь себе

← →
Игорь Шевченко © (2006-04-19 23:40) [327]

xayam © (19.04.06 23:28) [326]

> ...а кто не придерживается беспомощен. Так что ли?

А кто не придерживается, не обменивается со мной данными. Так я доступно излагаю ?

> Да кто тебе сказал, что это первостепенная задача?

Область задач моей предметной области сказала.

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

Не понял, поясни. Особенно фразу насчет полей и строк. Ты считаешь, что 100 полей лучше чем 100 строк или как ? И какое отношение ко всему этому имеет нормализация ?

> сущности, улучшающие структуру (архитектуру, основу - как
> хочешь назови), не могут быть лишними!

Могут. И я привел пример в одном из предыдущих постов. Вот объясни мне, каким образом введенные лишние сущности (объекты базы данных для генерации синтетических уникальных значений, сопоставляемых с естественно уникальными значениями) улучшат архитектуру моей системы. Если не трудно, объясни подробнее.

> Ты противоречишь себе

Суть стандарта - каждая страна имеет свой уникальный код. В чем я себе противоречу ?

← →
xayam © (2006-04-20 00:06) [328]

> Игорь Шевченко © (19.04.06 23:40) [327]

> А кто не придерживается, не обменивается со мной данными

Очень надо было))

> Область задач моей предметной области сказала.

Какая?

> Ты считаешь, что 100 полей лучше чем 100 строк или как ?

100 полей - это, можно сказать, константа, а количество строк - переменная. Их нельзя сравнивать.

> И какое отношение ко всему этому имеет нормализация ?

Так, так домашнее задание не сделали, не узнали что такое нормализация. Есть такое понятие Универсальная Отношение, такая большая таблица, которая изначально содержит все поля и строки, включая дублирующие. Так вот в процессе нормализации (разделения, декомпозиции - как хочешь) количество таблиц увеличивается, строк, относящихся к какому-либо факту, уменьшается. И этот процесс необходим, если Вы хотите исключить из базы избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Окончательная цель - каждый факт появляется лишь в одном месте.

> Суть стандарта - каждая страна имеет свой уникальный код

А про ком ты уже забыл?

> В чем я себе противоречу ?

"Никакого изменения стандарта нет". Скорей всего ты хочешь сказать, что он обратно совместим.

← →
Игорь Шевченко © (2006-04-20 00:21) [329]

xayam © (20.04.06 00:06) [328]

> Очень надо было))

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

> И этот процесс необходим, если Вы хотите исключить из базы
> избыточность информации

Спасибо, у меня избыточность исключительно в разумных пределах. Как ты читал дальше, нормализация - это конечно очень хорошо, но не очень производительно.

> А про ком ты уже забыл?

???? Про какой ком ?

> "Никакого изменения стандарта нет". Скорей всего ты хочешь
> сказать, что он обратно совместим

Нет. Никакого изменения стандарта нет. СССР был точно такой же страной, какой является Россия и имеет свой уникальный код. Ни о совместимости ни об изменениях речь не идет.

> 100 полей - это, можно сказать, константа, а количество
> строк - переменная. Их нельзя сравнивать.

Еще раз: ты сказал, что проблема с разными названиями стран на разных языках решается добавлением поля с названием на другом языке. В посте [326] ты сказал, что добавишь 100 полей, если надо учитывать названия на 100 языках. Тебе не кажется, что ты в этом случае сильно отступаешь от нормализации ?

← →
xayam © (2006-04-20 00:22) [330]

> Игорь Шевченко © (19.04.06 23:40) [327]

> каким образом введенные лишние сущности улучшат архитектуру
> моей системы

очень просто - она не будет зависеть от внешнего мира (о чем я писал в самом начале). Круг замкнулся?

← →
xayam © (2006-04-20 00:32) [331]

> Игорь Шевченко © (20.04.06 00:21) [329]

> Я не ставлю себе всеобъемлющих задач

вот это зря

> нормализация - это конечно очень хорошо, но не очень производительно

о какой производительности ты говоришь? Которую не хочешь признавать на примерах Jeer"а ?

> Нет. Никакого изменения стандарта нет. СССР был точно такой
> же страной, какой является Россия и имеет свой уникальный
> код. Ни о совместимости ни об изменениях речь не идет.

...без комментариев

> Еще раз: ты сказал, что проблема с разными названиями стран
> на разных языках решается добавлением поля с названием на
> другом языке. В посте [326] ты сказал, что добавишь 100
> полей, если надо учитывать названия на 100 языках.

сделать перевод

> Тебе не кажется, что ты в этом случае сильно отступаешь
> от нормализации ?

В чем? Конкретнее?

← →
xayam © (2006-04-20 00:42) [332]

> Игорь Шевченко © (20.04.06 00:21) [329]
> > А про ком ты уже забыл?
> ???? Про какой ком ?

xayam © (19.04.06 17:52) [319]

← →
Lamer@fools.ua © (2006-04-20 00:42) [333]

>>Игорь Шевченко © (19.04.06 22:56) [325]

>А во внешнем мире не бывает уникальных значений ? :) На мой взгляд, бывают. Впрочем, до тех пор, пока их, в качестве уникальных, придерживаются те источники, с которыми мне нужно обмениваться данными, меня имеющаяся уникальность устраивает. Ну и заодно, мне не нужно делать дополнительных запросов при импорте, для выяснения того, какой синтетический ключ соответствует пришедшему коду, что на производительности тоже достаточно благотворно сказывается.
Даже если ПК у меня СК, ничто мне не мешает в данный момент, пока действует какая-то договорённость об уникальности поля (стандарт или спецификация по обмену данными с другими системами) навесить ограничение уникальности на, скажем, ISO-код страны (или региона?) и использовать ISO-код для синхронизации, например, с Вашей системой. Вполне возможно, что пройдёт время и придумают новый стандарт, а на старый махнут рукой. Что тогда делать, если ПК — ISO-код? Придумывать алгоритм генерации? Либо изменять структуру БД и обновлять данные, чтобы использовать новый код? С некоторой стороны это, конечно, выгодно — есть за что брать деньги :-)

Резюмирую. IMHO, СК бывает и излишним, но добавляет универсальность и унифицированность.

>Опять же, я свою точку зрения никому не навязываю, просто продолжаю считать, что естественные ключи (или бизнес-ключи, по терминологии автора Keytaxonomy2005) тоже имеют право на существование в структуре базы данных...
Да пускай себе существуют. Но не в виде ПК, а в виде UNIQUE CONSTRAINT"ов :-)
Я, собственно, тоже не навязываю. Да и хлопотно и накладно это как-то — навязывать :-)

>...и соображения об их неиспользовании выглядят в большей
степени религиозными, нежели практическими.
IMHO, холиворы интереснее наблюдать со стороны, чем принимать в них непосредственное участие :-)

← →
Игорь Шевченко © (2006-04-20 00:43) [334]

xayam © (20.04.06 00:22) [330]

> очень просто - она не будет зависеть от внешнего мира

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

> вот это зря

Почему ?

> о какой производительности ты говоришь? Которую не хочешь
> признавать на примерах Jeer"а ?

Будет скрипт, будет производительность. Я говорю о той производительности, падение которой является оборотной стороной нормализации. Я приводил статью KeyTaxonomy2005, там этот момент тоже, по-моему, упоминается.

> сделать перевод

> В чем? Конкретнее?

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

> ...без комментариев

Я что-то сказал не так или ты, наконец, согласился ? :)

← →
xayam © (2006-04-20 00:48) [335]

> Lamer@fools.ua © (20.04.06 00:42) [333]
> Но не в виде ПК, а в виде UNIQUE CONSTRAINT"ов :-)

поддерживаю

← →
Игорь Шевченко © (2006-04-20 00:53) [336]

Lamer@fools.ua © (20.04.06 00:42) [333]

> ничто мне не мешает в данный момент, пока действует какая-
> то договорённость об уникальности поля (стандарт или спецификация
> по обмену данными с другими системами) навесить ограничение
> уникальности на, скажем, ISO-код страны (или региона?) и
> использовать ISO-код для синхронизации, например, с Вашей
> системой. Вполне возможно, что пройдёт время и придумают
> новый стандарт, а на старый махнут рукой. Что тогда делать,
> если ПК — ISO-код?

Сдается мне, что ко времени изменения стандарта ISO накопится масса других, более актуальных изменений в структуре базы данных.

Но и это не главное. А главное то, что этих стандартов придерживаются системы, с которыми я взаимодействую, что для меня гораздо важнее, чем уповать на то, что стандарты, дескать, поменяются. Кстати, стандарты ISO не меняются. Могут появляться новые стандарты, но старые не исчезают.

> Резюмирую. IMHO, СК бывает и излишним, но добавляет универсальность
> и унифицированность.

А какой выигрыш дает универсальность и унифицированность, что ради нее нужно вводить лишние механизмы ?

> Да пускай себе существуют. Но не в виде ПК, а в виде UNIQUE
> CONSTRAINT"ов :-)

А какой смысл держать два уникальных constraint в одной сущности ? Я понимаю, когда одно поле используется для связки, потому что небольшое, а другая группа полей составляет уникальный constraint, но в моем случае вроде оба поля небольшие и вполне могут использоваться для связки.

ЗЫ: Оффтопик: А чего ты старым ником не пользуешься ? :)

← →
xayam © (2006-04-20 01:07) [337]

> Игорь Шевченко © (20.04.06 00:43) [334]
> А между названиями на разных языках зависимость

соответствие.
Я правильно понял?
ID Pole_ISO Pole_Rus Pole_Eng Pole_Fr ...
0 RU Россия Russia La Russie Rusia Rußland
1 UK ...
...
----------------------------------------------------------------

> Я что-то сказал не так

Да и не спрашивай что. Почитай сам свой текст

> или ты, наконец, согласился ?

нет, но не парься, как [] догоним до 1000, я над этим подумаю))

← →
Lamer@fools.ua © (2006-04-20 01:10) [338]

>>Игорь Шевченко © (20.04.06 00:53) [336]

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

>А какой смысл держать два уникальных constraint в одной сущности ? Я понимаю, когда одно поле используется для связки, потому что небольшое, а другая группа полей составляет уникальный constraint, но в моем случае вроде оба поля небольшие и вполне могут использоваться для связки.
На компрометирующие мою религию вопросы я буду отвечать только в присутствии Анатолия Тенцера :-))
А вообще сложно ответить, не видя конкретного SRS. Вполне допускаю, что в тех типах систем, с которыми я не сталкивался, ЕК рулят, а СК — сакс и мастдай.

>ЗЫ: Оффтопик: А чего ты старым ником не пользуешься ? :)
Даже сам не знаю.
Может, потому что под этим ником я в большем количестве форумов зарегистрирован и решил, так ска-ать и тут провести унификацию :-)
Или может, потому что почти перестал отвечать в тематических конференциях, а для потрепаловки этот ник в самый раз.

← →
Игорь Шевченко © (2006-04-20 01:13) [339]

xayam © (20.04.06 01:07) [337]

> Я правильно понял?
> ID Pole_ISO Pole_Rus Pole_Eng Pole_Fr ...
> 0 RU Россия Russia La Russie Rusia
> Rußland
> 1 UK ...

Ты этот вариант хочешь предложить ? Я не принимаю. Количество языков, с которыми мне приходится общаться, переменный. В сторону увеличения.

> > Я что-то сказал не так
>
> Да и не спрашивай что. Почитай сам свой текст

Я свой текст читаю. Если ты видишь в нем несоответстие чему-то, то ты не стесняйся, а прямым текстом укажи, где я неправ.

> нет, но не парься, как [] догоним до 1000, я над этим подумаю))

Я не в бане, дружок.

← →
Anatoly Podgoretsky © (2006-04-20 01:18) [340]

А что тебя взволновал СОМ, какое он отношение к странам имеет?

← →
Игорь Шевченко © (2006-04-20 01:18) [341]

Lamer@fools.ua © (20.04.06 01:10) [338]

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

Так об чем большевики твердят на протяжении всей этой ветки до хрипоты - что каждый овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время :)

> А вообще сложно ответить, не видя конкретного SRS.

И это большевики еще в самом начале ветки говорили :) Каждой системе, по-хорошему, не вредит свой подход со своими же тараканами.

> Или может, потому что почти перестал отвечать в тематических
> конференциях

А это зря, кстати :) В той же WinAPI, например.

← →
xayam © (2006-04-20 01:19) [342]

> Игорь Шевченко © (20.04.06 01:13) [339]

> прямым текстом укажи, где я неправ.

А я указал xayam © (19.04.06 23:28) [326]

> Количество языков, с которыми мне приходится общаться, переменный.
> В сторону увеличения.

Переменный, но ограниченный числом, скажем, 100. А количество строк - их же может быть куда больше.

← →
xayam © (2006-04-20 01:21) [343]

> Anatoly Podgoretsky © (20.04.06 01:18) [340]

читайте пожалуйста все, и я сказал "ком", а не "COM".

← →
xayam © (2006-04-20 01:24) [344]

> Игорь Шевченко © (20.04.06 01:13) [339]
> с которыми мне приходится общаться

Может ты все таки откроешь свою область деятельности, можешь на почту, я никому не скажу))

← →
Игорь Шевченко © (2006-04-20 01:27) [345]

> > Заметь, стандарт не меняется. Была сущность СССР, кодировалась
>
> > определенным сочетанием. Появилась самостоятельная сущность
>
> > Россия, для нее выбрано другое сочетание. Никакого изменения
>
> > стандарта нет.
>
> Ты противоречишь себе

Под сущностью имеется в виду экземпляр сущности типа страна, если быть до конца точным. И СССР и Россия - это страны.

Теперь возражений нет ?

← →
xayam © (2006-04-20 01:30) [346]

> Игорь Шевченко © (20.04.06 01:27) [345]
> экземпляр сущности типа страна, если быть до конца точным.
> И СССР и Россия - это страны

еще раз - СССР нет, что ты за нее так держишься?

← →
Anatoly Podgoretsky © (2006-04-20 08:53) [347]

xayam © (20.04.06 01:30) [346]
Если бы было все так просто в базах, пропала сущность, стерли ее, что бы за нее не держаться и глаза не можолить.

← →
Игорь Шевченко © (2006-04-20 10:13) [348]

xayam © (20.04.06 01:30) [346]

Еще два раза - до 1991 года он был, а стандарт был сделан несколько раньше.

И бились они три дня и три ночи, и не было им усталости

> Игорь Шевченко © (20.04.06 10:13) [348]
> Еще два раза - до 1991 года он был, а стандарт был сделан
> несколько раньше.

Да какая разница раньше, позже. Стандарт изменился, упоминание об СССР осталось (я правильно понял?), чтобы никто не использовал это сочетание. А зачем мне в базе отражать историю стандарта, скажите? База данных - отражение реальности, то что есть, ни больше, ни меньше.

xayam © (20.04.06 10:46) [350]

> А зачем мне в базе отражать историю стандарта, скажите?

А тебя кто-то заставляет отражать ? Вроде нет.

> Игорь Шевченко © (20.04.06 10:47) [351]

Стоп. С этого места подробнее. Не заставлял? О какой поддерже стандарта ты тогда говоришь? Пожалуйста приведи свой вариант таблицы, которая была выше.

xayam © (20.04.06 10:54) [352]

Я говорю о том, что код ISO используется в качестве первичного ключа в таблицах, описывающих географические понятия, и в качестве поля для связки. И все. Про СССР начал ты говорить.

> Игорь Шевченко © (20.04.06 10:57) [353]

> Я говорю о том, что код ISO используется в качестве первичного
> ключа в таблицах, описывающих географические понятия, и
> в качестве поля для связки.

страны

> Про СССР начал ты говорить.

да, но таких СССР в стандарте все больше и больше - вот это и есть ком. Ну может не очень хорошее сравнение, скажи сосулька - она все больше и больше намерзает, а когда упадет. Ты знаешь об этом?

> Я говорю о том

А со 100 полями у тебя как, по-другому?

Игорь Шевченко © (20.04.06 10:57) [353]
> Я говорю о том, что код ISO используется в качестве первичного ключа в таблицах, описывающих географические понятия,
> и в качестве поля для связки.

используете и используйте на здоровье... скажите только код у вас этот только для связок, или еще и в отчетах гденибудь используется? /в таблицах/для выбора из списка? т.е. юзер его видит? думаю да.

и теперь представьте ситуацию, клиент "заартачился", не хочу говорит видеть код в ISO 639-1 варианте, хочу в ISO 639-2 ....
http://ru.wikipedia.org/wiki/ISO_639
и ? он у вас уже в куче документов за 6 лет (к примеру) присутствует, + в архивах, на местах в распределенной системе.

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

это к вопросу о

sniknik © (17.04.06 11:37) [81]
> исправить сложнее, если конечно ИНН используется как естественный ключь.
Игорь Шевченко © (17.04.06 11:40) [82]
> sniknik © (17.04.06 11:37) [81]
> Может, я чего здорово не понимаю, но в чем именно сложность ?

иправлений, ошибочно введенных ИНН.

p.s. возможно аргумент не раз уже приводили... сорри, перестал следить за веткой.
p.p.s. а после того как исправите, клиент посмотрит и скажет "не, раньше лучше было" ;о)))

>>sniknik © (20.04.06 11:35) [356]
Не человек для субботы, а суббота для человека :)
У них клиенты не артачатся, они с такими не работают

> Внук © (20.04.06 11:42) [358]
> >>sniknik © (20.04.06 11:35) [356]
> они с такими не работают

)) Очень надо было скажет

sniknik © (20.04.06 11:35) [356]

> и теперь представьте ситуацию, клиент "заартачился",

Даже представлять не буду. Если под каждого клиента навешивать свои рюшечки, это значит, обрекать себя на непроизводительный геморрой. А оно надо ?

Первичный ключ Найти похожие ветки