Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 5 >
DmitrichJ © (2007-08-02 14:18:00)
Допустим в базе есть несколько абсолютно одинаковых записей в 2-х полях:

| name | code |
1. | "Вася" | 0 |
2. | "Вася" | 0 |
3. | "Вася" | 0 |

и мне нужно одной, любой из этих записей изменить значение code.

Или всё же нужно создовать идентифицирующее поле np?

TohaNik (2007-08-08 12:19:00) [21]

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

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

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

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

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

Sergey13 (2007-08-08 11:42:00) [22]
> [70] Игорь Шевченко © (08.08.07 11:31)

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

Игорь Шевченко (2007-08-08 11:31:00) [23]
Sergey13 © (08.08.07 11:28) [69]

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

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

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

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

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

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

Игорь Шевченко (2007-08-08 11:08:00) [25]
TohaNik © (08.08.07 10:33) [67]

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

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

TohaNik (2007-08-08 10:33:00) [26]
Есть у меня одна база, где МФО банка первичный ключ. Четыре года как бы и ничего, но тут название банка поменяли. Ну выкрутился ввел с минусом.:)), в отчетах убираю.

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

Игорь Шевченко (2007-08-08 10:05:00) [27]
Sergey13 © (08.08.07 08:41) [64]

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

Игорь Шевченко (2007-08-08 10:03:00) [28]
MsGuns © (07.08.07 17:01) [52]

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

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

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

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

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

MsGuns © (07.08.07 21:59) [59]

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

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

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

Sergey13 (2007-08-08 08:41:00) [29]
> [54] Anatoly Podgoretsky © (07.08.07 19:49)

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

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

MsGuns (2007-08-07 23:05:00) [30]
Не знаю, не знаю..
Было время, когда я был ярым противником "суррогатных" ключей, считая их "наростом" на информации, увеличивающим избыточность. Зато конструкции с повторами ключей типа нижеприведенной считал за единственно верный путь:

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

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

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

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

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

Anatoly Podgoretsky (2007-08-07 22:29:00) [31]

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

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

Anatoly Podgoretsky (2007-08-07 22:26:00) [32]
> MsGuns (07.08.2007 21:50:58) [58]

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

sdts (2007-08-07 22:09:00) [33]

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

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

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

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

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

MsGuns (2007-08-07 21:50:00) [35]
>Anatoly Podgoretsky © (07.08.07 19:53) [56]

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

sdts (2007-08-07 21:43:00) [36]

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

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

Anatoly Podgoretsky (2007-08-07 19:53:00) [37]
> TMegaMaster(Lamer) (07.08.2007 18:03:53) [53]

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

Anatoly Podgoretsky (2007-08-07 19:50:00) [38]
> TMegaMaster(Lamer) (07.08.2007 18:03:53) [53]

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

Anatoly Podgoretsky (2007-08-07 19:49:00) [39]
> Sergey13 (07.08.2007 14:03:49) [49]

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

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

TMegaMaster(Lamer) (2007-08-07 18:03:00) [40]

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

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

Страницы: < 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »