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

← →
DmitrichJ (2007-08-02 14:18) [0]

Допустим в базе есть несколько абсолютно одинаковых записей в 2-х полях:

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

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

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

← →
Kolan © (2007-08-02 14:21) [1]

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

Ну а как ты хотел? Ессно создай ID. Ты его в примере даже сделал:
1. | «Вася» | 0 | 2. | «Вася» | 0 | 3. | «Вася» | 0 |

← →
DmitrichJ (2007-08-02 14:28) [2]

Просто думал мало ли есть способ. А то в моей задаче там ID трудновато будет реализовать

← →
clickmaker © (2007-08-02 14:30) [3]

> моей задаче там ID трудновато будет реализовать

почему?

← →
DmitrichJ (2007-08-02 14:32) [4]

черезчур много таблиц и генераторов. Но, видимо, придётся всё же делать...

← →
StriderMan © (2007-08-02 14:36) [5]

> и генераторов

а генераторы для чего используются?

← →
Sergey13 © (2007-08-02 14:40) [6]

> [4] DmitrichJ (02.08.07 14:32)
> черезчур много таблиц и генераторов

Через чур много - это как? Если лишние поудаляй - ты же хозяин/разработчик.
Судя по "базе есть несколько абсолютно одинаковых записей" надо еще немало поработать над структурой. И

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

только убеждает в этом.

← →
Desdechado © (2007-08-02 19:51) [7]

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

← →
TMegaMaster(Lamer) (2007-08-02 19:56) [8]

Совет на будущее - создавай поле ID ВСЕГДА. Даже если кажется что оно вроде и не нужно. Ну и по сбжу - добавь такие поля в таблицах, где их нет, потому как в противном случае ты будешь каждый день подобные вопросы задвать

← →
Кщд © (2007-08-03 14:48) [9]

>TMegaMaster(Lamer) (02.08.07 19:56) [8]
мозги не пудрили бы бодаванам юным догмой религиозной))

← →
Sergey13 © (2007-08-03 15:05) [10]

> [9] Кщд © (03.08.07 14:48)

Это не вредная догма.8-)

← →
Anatoly Podgoretsky © (2007-08-03 15:14) [11]

А база то есть?

← →
sdts (2007-08-03 15:31) [12]

> любой из этих записей изменить значение code

собственно а почему не всем, если не имеет значение какой?
update table set code=1 where name="Вася"
:)

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

> Кщд © (03.08.07 14:48) [9]
> >TMegaMaster(Lamer) (02.08.07 19:56) [8]
> мозги не пудрили бы бодаванам юным догмой религиозной))

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

← →
Кщд © (2007-08-06 08:57) [14]

>Sergey13 © (03.08.07 15:05) [10]
естественные против суррогатных, принципиальная необходимость первичных или наоборот и т.д. - это специфика задачи и богатство опыта))
а "создавай поле ID ВСЕГДА тчк" - это религия, не находите?)

← →
Sergey13 © (2007-08-06 09:08) [15]

> [14] Кщд © (06.08.07 08:57)

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

← →
MsGuns © (2007-08-06 09:43) [16]

>Кщд © (06.08.07 08:57) [14]
>а "создавай поле ID ВСЕГДА тчк" - это религия, не находите?)

Один мой друг, автомобилист, когда едет, всегда поглядывает в зеркало заднего обзора. Даже если шоссе пустынно.
Он религиозный фанат ?

← →
Anatoly Podgoretsky © (2007-08-06 10:04) [17]

Может и вредить, например излишностью.

← →
Кщд © (2007-08-06 10:07) [18]

>Sergey13 © (06.08.07 09:08) [15]
лично мне ближе позиция монаха уильяма))

>MsGuns © (06.08.07 09:43) [16]
перед тем, как перейти дорогу: смотрю налево, смотрю направо
даже если дорога пуста
казалось бы, какое это имеет отношение к проектированию баз данных?))

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

← →
Sergey13 © (2007-08-06 10:10) [19]

> [17] Anatoly Podgoretsky © (06.08.07 10:04)

Излишность в данном конкретном случае, ИМХО, можно обозвать, например, дополнительной степенью защиты от человеческого фактора. 8-)

← →
Jeer © (2007-08-06 10:34) [20]

Действительно, оставим в стороне вопрос о ПК и ЕК, излишествах..

Но, если в таблице одно поле NAME и нет unique индекса, то отличать одну запись от другой при совпадении значений в NAME можно будет только по физическому номеру записи, что уже полный бред.

← →
Anatoly Podgoretsky © (2007-08-06 10:42) [21]

> Sergey13 © (06.08.07 10:10) [19]

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

← →
Sergey13 © (2007-08-06 10:52) [22]

> [21] Anatoly Podgoretsky © (06.08.07 10:42)
> никакой это защиты не дает.

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

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

← →
MsGuns © (2007-08-06 12:02) [23]

За редким исключением рекомендую использовать в качестве ПК уникальный идентификатор (автоинремент,генератор, последовательность..) - преимуществ масса: от скорости выборок до мобильности данных в таблицах (независимость ХРАНЕНИЯ данных от их СОДЕРЖАНИЯ)

← →
Anatoly Podgoretsky © (2007-08-06 12:27) [24]

Sergey13 © (06.08.07 10:52) [22]
По приведеному тобой примеру обретешь теже самые проблемы, просто это будет не в первичном ключе, а в поле, к тому же избыточность, второе поле тоже придется делать уникальным и оно по сути будет дублировать ключ, отличаясь только информацией в поле.
А вот что дополнительно неприятного получишь, так это что тебе придется самому поддерживать каскадную целостность при апдейте, либо запросом, либо триггерами, но придется. А в случае выбора в качестве кандидата на первичной ключ, этой работой мог бы заниматься сервер, гарантируя целостность базы. Естественно относится только к тем сервервам, которые поддерживают Cascade Update/

Ну а преимущества ИК указаны в MsGuns © (06.08.07 12:02) [23]

← →
Jeer © (2007-08-06 12:28) [25]

> За редким исключением

У меня даже исключений для применения ЕК не находилось до сих пор.

← →
Anatoly Podgoretsky © (2007-08-06 12:32) [26]

> Jeer (06.08.2007 12:28:25) [25]

По статистике, более 99% ключей искуственные, и где надо и где не надо.

← →
Sergey13 © (2007-08-06 13:05) [27]

> [24] Anatoly Podgoretsky © (06.08.07 12:27)
> А вот что дополнительно неприятного получишь, так это что
> тебе придется самому поддерживать каскадную целостность
> при апдейте

Я ж говорю, что для связей использую только ИК (для них собственно он у меня избыточно и вводится). Так что как раз тут все нормально. Вот если для связей использован ЕК, тогда да, там где каскадного апдейта нет - придется покорпеть в случае замены в ПК.

← →
MsGuns © (2007-08-06 14:17) [28]

>Jeer © (06.08.07 12:28) [25]
>У меня даже исключений для применения ЕК не находилось до сих пор.

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

← →
TMegaMaster(Lamer) (2007-08-06 16:16) [29]

Все вы говорите верно, есть еще и фактор удобства для программирования. Когда вы знаете, что в любой таблице ПК - это поле ID, Вам гораздо проще сделать универсальный механизм доступа к данным. Про построение распределенной БД говорить даже не надо - там даже исключение, описанное
> MsGuns © (06.08.07 14:17) [28]

работать не будет.

← →
Fredy314 © (2007-08-07 00:08) [30]

LIMIT 1; попробуй в конце добавить

← →
Виталий Панасенко(дом) (2007-08-07 01:12) [31]

> Fredy314 © (07.08.07 00:08) [30]
>
> LIMIT 1; попробуй в конце добавить
>

и при этом установить MySQL?...:-\

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

Sergey13 © (06.08.07 10:52) [22]

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

Ты мазохист

MsGuns © (06.08.07 12:02) [23]

> За редким исключением рекомендую использовать в качестве
> ПК уникальный идентификатор (автоинремент,генератор, последовательность.
> .) - преимуществ масса: от скорости выборок до мобильности
> данных в таблицах (независимость ХРАНЕНИЯ данных от их СОДЕРЖАНИЯ)

А вот Joe Celko не рекомендует. Кому из вас верить ?

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

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

> Все вы говорите верно, есть еще и фактор удобства для программирования.

Фактор удобства программирования - это отмазка лентяев.

← →
Sergey13 © (2007-08-07 11:37) [34]

> [32] Игорь Шевченко © (07.08.07 11:32)
> Я тебе могу поведать печальную сагу

У многих тут есть примеры печальных саг.

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

Sergey13 © (07.08.07 11:37) [34]

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

← →
Sergey13 © (2007-08-07 11:47) [36]

> [35] Игорь Шевченко © (07.08.07 11:41)

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

ЗЫ: Вообще надоели уже эти споры ЕК vs ИК.

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

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

Видишь ли, регулярно встречал объявления

CREATE TABLE foo (
ID NUMBER PRIMARY KEY,
NAME VARCHAR2(32) UNIQUE,
....
);

Как ты понимаешь, сегодня-завтра в такой таблице рояли не играет.

← →
Sergey13 © (2007-08-07 11:56) [38]

> [37] Игорь Шевченко © (07.08.07 11:53)
> сегодня-завтра в такой таблице рояли не играет

Почему? Завтра может стать
NAME VARCHAR2(64) UNIQUE
а после завтра просто
NAME VARCHAR2(32)

Какую конкретно из 10 заповедей нарушает ID NUMBER PRIMARY KEY в этой таблице? Кому от этого плохо?

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

Sergey13 © (07.08.07 11:56) [38]

> Какую конкретно из 10 заповедей нарушает ID NUMBER PRIMARY
> KEY в этой таблице?

Седьмую, разумеется :)

Я не понимаю, а нафига это поле ?

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

← →
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)

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

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

MsGuns © (07.08.07 17:01) [52]

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

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

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

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

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

MsGuns © (07.08.07 21:59) [59]

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

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

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

Sergey13 © (08.08.07 08:41) [64]

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

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

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

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)
> Свойство - оно же не само по себе живет, верно ? Тебе ж
> с ним как-то работать надо ? А если не надо - то нафига
> оно вообще ?

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

← →
TMegaMaster(Lamer) (2007-08-08 13:21) [81]

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

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

DrPass © (08.08.07 12:29) [78]

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

Не МФО, а название ? МФО, насколько я понимаю, не поменялся ?

TohaNik © (08.08.07 12:29) [77]

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

Да неважно. В отчете тебе что надо, кроме названия ?

Sergey13 © (08.08.07 13:05) [80]

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

То есть, ИНН станет неуникальным и поиск у тебя выдаст вместо одной сотню записей - это пофиг, я верно тебя понимаю ?
Тогда тебе не стоит связывать по ИНН...

> Игорь Шевченко © (08.08.07 13:38) [82]

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

В вопрос не въехал.
Наверно мы совсем не знатоки в вопросах банков. :)

> [83] Игорь Шевченко © (08.08.07 13:39)
> поиск у тебя выдаст вместо одной сотню записей - это пофиг

Конечно пофиг. А если по фамилии искать то может и тысячу выдаст. И что? У тебя все поиски выдают единичные результаты?

Sergey13 © (08.08.07 14:06) [85]

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

> [86] Игорь Шевченко © (08.08.07 14:44)
> Видишь ли, я не знаю твоей задачи, ты не знаешь моих. Вполне вероятно, что твое средство от геморроя мне не подойдет по одной причине - у меня его нету :)

Вполне, даже очень вероятно, что задачи разные. Гемороя у меня тоже нет, т.к. мое средство профилактическое. 8-)

ЗЫ: Только хотелось бы на основании различий решаемых задач не получать в свой адрес обвинений в мазохизме и прочих интересных пожеланий в полевых условиях.

Удалено модератором

> Игорь Шевченко © (08.08.07 13:38) [82]

> Не МФО, а название ? МФО, насколько я понимаю, не поменялся
> ?

Да, т.к. необходимо хранить историю изменений - какие названия в какой период времени были закреплены за данным МФО. Это необходимо для корректного формирования платежных документов

DrPass © (08.08.07 16:32) [89]

Вполне согласен

Sergey13 © (08.08.07 15:25) [87]

> ЗЫ: Только хотелось бы на основании различий решаемых задач
> не получать в свой адрес обвинений в мазохизме и прочих
> интересных пожеланий в полевых условиях.

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

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