UpDate. Как изменить одну запись, если их несколько одинаковых?

← →
Sergey13 © (2007-08-07 12:47) [40]

> [39] Игорь Шевченко © (07.08.07 12:08)
> Седьмую, разумеется :)
Седьмая - это искусственный ключ. Пользуйся естественным. 8-)

> Я не понимаю, а нафига это поле ?
Средство от гемороя. Пусть это и кажется тебе навязчивой идеей, граничащей с манией преследования. Ввести одно поле за свое спокойствие - нормальная цена, ИМХО, особенно если нервные клетки не восстанавливаются.

> храни все данные в 4-х таблицах
Ты только эти варианты приемлешь?

← →
Anatoly Podgoretsky © (2007-08-07 13:31) [41]

> Сегодня неавтоинкрементное уникальное поле наличествует, завтра не наличествует, послезавтра наличествует неуникальное.

Сегодня ИК наличествует, завтра не наличествует, послезавтра наличествует ЕК.

это не может быть аргументом.

← →
Anatoly Podgoretsky © (2007-08-07 13:36) [42]

> Sergey13 (07.08.2007 12:47:40) [40]

Это цена не нормальная, поскольку придется поддерживать каскадное обновление руками, беспокоиться об целостности и держать рядом ненужное поле.

← →
Sergey13 © (2007-08-07 13:38) [43]

> [41] Anatoly Podgoretsky © (07.08.07 13:31)

Естественный ключ помрет естественной смерью, а искусственный только искусственной, т.е. преднамеренным убийством. 8-)

← →
Sergey13 © (2007-08-07 13:40) [44]

> [42] Anatoly Podgoretsky © (07.08.07 13:36)

Почему? При наличии ИК, ЕК просто лежит рядом В ОДНОЙ ТАБЛИЦЕ как дополнительный уникальный ключ. Где его каскадно обновлять то надо?

← →
Игорь Шевченко © (2007-08-07 13:46) [45]

Sergey13 © (07.08.07 12:47) [40]

> Седьмая - это искусственный ключ. Пользуйся естественным.
> 8-)

Седьмая - это "не прелюбодействуй".

> Средство от гемороя. Пусть это и кажется тебе навязчивой
> идеей, граничащей с манией преследования.

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

Не хочешь Целко читать, почитай Усова:

http://www.alexus.ru/russian/articles/dbms/keys/page01.htm

← →
Sergey13 © (2007-08-07 13:52) [46]

> [45] Игорь Шевченко © (07.08.07 13:46)
> Но я не понимаю, зачем при наличии уникального ключа делать еще и автогенерируемый.
Только из-за того, что не уверен в незыблемости этого самого уникального естественного ключа.

← →
Anatoly Podgoretsky © (2007-08-07 13:53) [47]

> Sergey13 (07.08.2007 13:38:43) [43]

Оба они плохо кончат.
Ключи просто так, абы как не меняют, да и необходимости менять их практически нет.

← →
Anatoly Podgoretsky © (2007-08-07 13:54) [48]

> Sergey13 (07.08.2007 13:40:44) [44]

Ересь.
Первичный ключ может быть один на таблицу, не может быть два ключа.

← →
Sergey13 © (2007-08-07 14:03) [49]

> [47] Anatoly Podgoretsky © (07.08.07 13:53)
> Ключи просто так, абы как не меняют

Те кто меняет, меняют не ключи в таблицах, а сущности, отраженные в ключах. Этим людям до первичных ключей как до лампочки.

> [45] Игорь Шевченко © (07.08.07 13:46)
> Не хочешь Целко читать, почитай Усова:

Я знаком с предысторией вопроса.

ЗЫ: предлагаю завязать эту реинкарнацию древнего спора.

← →
Игорь Шевченко © (2007-08-07 14:13) [50]

> Те кто меняет, меняют не ключи в таблицах, а сущности, отраженные
> в ключах. Этим людям до первичных ключей как до лампочки.
>

делай 4 таблицы. Сразу радости всем будет

← →
Sergey13 © (2007-08-07 14:16) [51]

> [48] Anatoly Podgoretsky © (07.08.07 13:54)

А кто говорил про 2 ПК?

> [50] Игорь Шевченко © (07.08.07 14:13)
> делай 4 таблицы. Сразу радости всем будет

В следующий раз обязательно. Со ссылкой на авторитет.

← →
MsGuns © (2007-08-07 17:01) [52]

>Игорь Шевченко © (07.08.07 11:41) [35]
>Всех, кто делает ID при наличествующем неавтоинкрементном уникальном поле, необходимо выводить в чистое поле, ставить лбом к стенке и пускать пулю в лоб тремя очередями.

Ого ! По сравнению с "чемодан-вокзал-Урюпинск" это, прямо скажем, шаг вперед (или назад ?)

А теперь вопрос - ты во всех случаях при проектировании таблиц наверняка уверен, что вот это поле ВСЕГДА БУДЕТ СОДЕРЖАТЬ УНИКАЛЬНЫЕ ЗНАЧЕНИЯ ?
И еще вопрос - если у меня "этажерка" из 4-х связанных таблиц, то в последней мне надо иметь 4 ключа, причем ТРИ из них будут дублироваться. Что по этому поводу вещает твой классик жанра ? И что там насчет производительности выборок, особливо если ключи - стринги ?

<Цитата>

← →
TMegaMaster(Lamer) (2007-08-07 18:03) [53]

> Насчет скорости выборок - давай не надо. Я тебе могу поведать
> печальную сагу о разработчике, использующем ID везде, в
> результате, чтобы получить приемлемую выборку, ему часто
> приходится соединять 8-10 таблиц в запросе.

Ахинея какая-то. Приберегите этот аргумент против крайнего случая нормализации БД. Причем тут использование/неиспользование ИК? Ну откажется он от ID и будет вязать таблицы к примеру, по серии\номеру паспорта клиента, номеру накладной, еще какой-нибудь белиберде, которую вы громко называете ЕК. Завтра окажется, что номер накладной может повторяться а паспорта вообще отменили, куда будете жаловаться?

← →
Anatoly Podgoretsky © (2007-08-07 19:49) [54]

> Sergey13 (07.08.2007 14:03:49) [49]

> Те кто меняет, меняют не ключи в таблицах, а сущности, отраженные в ключах. Этим людям до первичных ключей как до лампочки.

И вот эти сущности и будут обрабатываться автоматически, без лишней работы.

← →
Anatoly Podgoretsky © (2007-08-07 19:50) [55]

> TMegaMaster(Lamer) (07.08.2007 18:03:53) [53]

Не стоит говорить о плохом проектирование и выдавать его за истину.

← →
Anatoly Podgoretsky © (2007-08-07 19:53) [56]

> TMegaMaster(Lamer) (07.08.2007 18:03:53) [53]

И кстати как это меняет ситуацию в случае уникального ключа, а ведь именно эту ситуацию и рассматриваем. Хоть ключ, хоть индекс "Завтра окажется, что номер накладной может повторяться"

← →
sdts (2007-08-07 21:43) [57]

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

всю ненадо, а вот про "приходится соединять 8-10 таблиц" ... и как от этого уйти ипользуя ЕК? было бы действительно и интересно и поучительно ...

← →
MsGuns © (2007-08-07 21:50) [58]

>Anatoly Podgoretsky © (07.08.07 19:53) [56]

Анатолий, он привел просто неудачный пример, но суть ты же понял отлично. А вот что прикажешь делать без суррогатного ключа например при построении БД типа "Кадры".
Что там взять за ключ ? ФИО ? Не годится.
Таб.Номер ? Не смешите тапочки - работник может иметь несколько номеров, если работает одновременно в нескольких подразделения да и при переходе с одного цеха в другой ТН меняется.
ФИО плюс дата рождения ? Редко, но совпадения могут быть и такие.
Добавить адрес ? И что тогда делать, если адрес изменится ? Каскадный апдэйт по всей базе и повесить базу намертво ? И как шустро будут итти выборки по такому монстроидальному ключу ?
ИНН ? Замечательно ! А если его нет ? А лет 7 назад и не было ни у кого !

← →
MsGuns © (2007-08-07 21:59) [59]

>sdts (07.08.07 21:43) [57]
>всю ненадо, а вот про "приходится соединять 8-10 таблиц" ... и как от этого уйти ипользуя ЕК? было бы действительно и интересно и поучительно ...

Ну это просто объяснить. Пример. Есть "кадровая структура" многоэтажной конструкции типа "Мастер"-"Детал"-"Детал 2"-"Детал 3"...
1. ИК ключи
Чтобы "вытянуть" информацию из "Детала 3", использую аргумент, представленный в "Мастере", нужно сделать трехуровневый join, т.к. таблицы "Мастер" и "Детал 3" между собою физически не связаны.
2. ЕК ключи
В "Детале 3" имеется весь "комплект" ключей, используемых в связке. Для извлечения данных из нее по ключу "Мастера" не надо делать никаких связок - т.е. сервер типа "отдохнет", копаясь лишь в одной таблице.

Подобную 2 технологию может отстаивать лишь человек, имеющий весьма небольшой опыт реального проектирования и администрирования БД и не знающий как сервера "любят" стринги, даже если они являются первичными ключами. Кроме того, наличие дополнительных полей (как правило стрингов немалого размера) начинает тормозить даже простую выборку из одной таблицы, даже если проиндексировать эти поля.

← →
sdts (2007-08-07 22:09) [60]

> MsGuns © (07.08.07 21:59) [59]

или чего-то не понял или ...
каким образом не меняя структуры (грубо говоря связи то остались прежними, только суть ключей поменялась как я понял из саги :)), они стали физически связаны во 2 варианте?

← →
Anatoly Podgoretsky © (2007-08-07 22:26) [61]

> MsGuns (07.08.2007 21:50:58) [58]

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

← →
Anatoly Podgoretsky © (2007-08-07 22:29) [62]

> ЗЫ: предлагаю завязать эту реинкарнацию древнего спора.

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

← →
MsGuns © (2007-08-07 23:05) [63]

Не знаю, не знаю..
Было время, когда я был ярым противником "суррогатных" ключей, считая их "наростом" на информации, увеличивающим избыточность. Зато конструкции с повторами ключей типа нижеприведенной считал за единственно верный путь:

Таблица 1
Ключ - [Номер цеха]

Таблица 2
Ключи - [Номер цеха], [Номер участка]

Таблица 3
Ключи - [Номер цеха], [Номер участка], [Номер бригады]

Таблица 4
Ключи - [Номер цеха], [Номер участка], [Номер бригады], [ФИО работника]

Теперь очень редко обхожусь без ИК. О преимуществах я уже говорил. Хотя есть масса "староверцев", в т.ч. с учеными званиями и опытом поболе моего, оставшихся на прежних позициях и не признающих суррогаты
Точно также как имеются аксакалы, не признающие ничего кроме парадокса или клиппера ;)

← →
Sergey13 © (2007-08-08 08:41) [64]

> [54] Anatoly Podgoretsky © (07.08.07 19:49)

Ты меня не понял. Я говорил про то, люди меняющие глобальные вещи, типа (для примера) ИНН, меньше всего думают, что этот самый ИНН где то служит первичным ключом и на его применение заточены множество работающих программных продуктов. Более того, возникает ощущение, что иногда они об этом "сознательно" не думают.
Вот сейчас ИНН есть не у всех. Мне представляется очень вероятным, что когда его рапространят на всех россиян, какого нибудь регистра не хватит, и мин.налогов объявит о замене формата этого ИНН, или вводе какого то другого идентификатора. Меняют же они каждый год форму налоговой отчетности, заставляя тем самым миллионы людей приобретать новые версии своих программ и/или дорабатывать старые.
А коды регионов? Мне почему то кажется, что скоро и тут грядет реформа. У Москвы вон уже несколько кодов на автомобильных номерах, У Питера вроде то-же. Некоторых кодов уже нет из-за слияния регионов. Ну и как опираться на такие, казалось бы, стойкие естественные ключи?

Я отнють не призываю всем и навсегда отказываться от ЕК. Я вообще уже никого ни к чему не призываю. Мне пофиг.
Я просто высказал свое видение этого вопроса. Мне лично, спокойнее работать с ИК.

← →
Игорь Шевченко © (2007-08-08 10:03) [65]

MsGuns © (07.08.07 17:01) [52]

> А теперь вопрос - ты во всех случаях при проектировании
> таблиц наверняка уверен, что вот это поле ВСЕГДА БУДЕТ СОДЕРЖАТЬ
> УНИКАЛЬНЫЕ ЗНАЧЕНИЯ ?

Если указан UNIQUE constraint, то как же там могут оказаться неуникальные значения ?

Сам посуди...

> И еще вопрос - если у меня "этажерка" из 4-х связанных таблиц,
> то в последней мне надо иметь 4 ключа, причем ТРИ из них
> будут дублироваться. Что по этому поводу вещает твой классик
> жанра ?

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

MsGuns © (07.08.07 21:59) [59]

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

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

Вот тогда мы углубимся в аспекты любви серверов к строкам.

← →
Игорь Шевченко © (2007-08-08 10:05) [66]

Sergey13 © (08.08.07 08:41) [64]

Ты же понимаешь, я надеюсь, что если грянет реформа, то ID-шники тебя не спасут ? Все равно, матчасть придется изменять.

← →
TohaNik © (2007-08-08 10:33) [67]

Есть у меня одна база, где МФО банка первичный ключ. Четыре года как бы и ничего, но тут название банка поменяли. Ну выкрутился ввел с минусом.:)), в отчетах убираю.

Я понимаю что ляп конечно, ну не знаю как переклинило тогда.
Так что согласен Sergey13, лучше перебдеть;)

← →
Игорь Шевченко © (2007-08-08 11:08) [68]

TohaNik © (08.08.07 10:33) [67]

> Есть у меня одна база, где МФО банка первичный ключ. Четыре
> года как бы и ничего, но тут название банка поменяли.

Я не знаток в вопросах банков, ты, может быть, пояснишь, в чем страх от изменения названия банки при наличии МФО (кстати, что это?) в качестве первичного ключа ?

> [65] Игорь Шевченко © (08.08.07 10:03)
> то я полемизировал с Sergey13, который утверждал, что в
> каждой таблице надо делать поле ID.

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

> [66] Игорь Шевченко © (08.08.07 10:05)
> Ты же понимаешь, я надеюсь, что если грянет реформа, то
> ID-шники тебя не спасут ? Все равно, матчасть придется изменять.

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

Sergey13 © (08.08.07 11:28) [69]

> Почему не спасут то? Мне с "лишними" ИД-шниками пофиг наличие
> естественного ключа - он несет дополнительную, справочно-
> поисковую функцию. Уйдет из жизни уникальность ключа - просто
> прибью ограничение. Изменится его формат и/или состав -
> просто изменю структуру и перепишу констрейнт. Общая функциональность
> табличных связей не изменится.

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

> [70] Игорь Шевченко © (08.08.07 11:31)

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

> Игорь Шевченко © (08.08.07 11:08) [68]

> Я не знаток в вопросах банков, ты, может быть, пояснишь,
> в чем страх от изменения названия банки при наличии МФО
> (кстати, что это?) в качестве первичного ключа ?

МФО, это некий числовой код филиала(отделения) банка.

Так вот он уникальный, иначе нарушится межфилиальный оборот(МФО), а название к нему печатается во всех платежных документах.

Был некий филиал банка "Аваль", а стал банка "Райфайзен-Аваль", старые платежки в архиве и меняться не должны, новые д.б. с новым названием.

PS
Я тоже не знаток в вопросах банков:)

Sergey13 © (08.08.07 11:42) [71]

Свойство - оно же не само по себе живет, верно ? Тебе ж с ним как-то работать надо ? А если не надо - то нафига оно вообще ?

TohaNik © (08.08.07 12:19) [72]

> МФО, это некий числовой код филиала(отделения) банка.
>
> Так вот он уникальный, иначе нарушится межфилиальный оборот(МФО),
> а название к нему печатается во всех платежных документах.
>
>
> Был некий филиал банка "Аваль", а стал банка "Райфайзен-
> Аваль", старые платежки в архиве и меняться не должны, новые
> д.б. с новым названием.

Что-то я не понимаю, каким бы образом тебе в этом вопросе помог бы ID-ник ? Ты бы завел новый банк с тем же МФО, но с другим названием ?

А денежки, пардон, как бы переехали ? :)

> Игорь Шевченко © (08.08.07 12:23) [75]

> А денежки, пардон, как бы переехали ? :)

Денюжкам название побоку, им МФО и счет подавай.

> Я не знаток в вопросах банков, ты, может быть, пояснишь,
> в чем страх от изменения названия банки при наличии МФО
> (кстати, что это?) в качестве первичного ключа ?

В том, что для сохранения корректности данных должна быть добавлена новая запись с тем же МФО, но с другим названием. МФО в принципе нельзя использовать в качестве первичного ключа, хоть он так и напрашивается на это. Естественным ключом в таблице банков в правильно спроектированной системе должен быть МФО + дата начала действия записи + дата окончания действия. И вполне логично в качестве первичного ключа здесь иметь суррогатный ID

Вообще, спор о преимуществе естественных/суррогатных ключей - довольно бестолковое занятие. Однозначного ответа здесь нет. Можно смело утверждать, что в большинстве случаев суррогатный ключ не повредит, и позволит избежать лишних подводных камней. Но бывают и исключения. Например, в типичном справочнике пользователей лучше использовать естественный ключ - логин. Это позволит избежать кучи лишних джойнов с разными журналами в тех случаях, когда надо выяснить логин юзера, выполнившего ту или иную операцию и т.д.

> [74] Игорь Шевченко © (08.08.07 12:21)
> Свойство - оно же не само по себе живет, верно ? Тебе ж
> с ним как-то работать надо ? А если не надо - то нафига
> оно вообще ?

Так работать то по разному можно. Вот ИНН везде печатать надо, искать по нему очень удобно. А вот таблицы связывать по нему - не хочу по вышеназванным причинам. Завтра сделают уникальность не по ИНН, а допустим по ИНН+ОКПО или еще как - мне пофиг, только чуток поиск поправить. А если бы я завязался на примари кей по ИНН - пол системы переделывать.

UpDate. Как изменить одну запись, если их несколько одинаковых? Найти похожие ветки