Мастера 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?

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

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

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

<Цитата>

Sergey13 (2007-08-07 14:16:00) [42]
> [48] Anatoly Podgoretsky © (07.08.07 13:54)

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

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

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

Игорь Шевченко (2007-08-07 14:13:00) [43]

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

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

Sergey13 (2007-08-07 14:03:00) [44]
> [47] Anatoly Podgoretsky © (07.08.07 13:53)
> Ключи просто так, абы как не меняют

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

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

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

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

Anatoly Podgoretsky (2007-08-07 13:54:00) [45]
> Sergey13 (07.08.2007 13:40:44) [44]

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

Anatoly Podgoretsky (2007-08-07 13:53:00) [46]
> Sergey13 (07.08.2007 13:38:43) [43]

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

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

Игорь Шевченко (2007-08-07 13:46:00) [48]
Sergey13 © (07.08.07 12:47) [40]

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

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

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

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

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

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

Sergey13 (2007-08-07 13:40:00) [49]
> [42] Anatoly Podgoretsky © (07.08.07 13:36)

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

Sergey13 (2007-08-07 13:38:00) [50]
> [41] Anatoly Podgoretsky © (07.08.07 13:31)

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

Anatoly Podgoretsky (2007-08-07 13:36:00) [51]
> Sergey13 (07.08.2007 12:47:40) [40]

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

Anatoly Podgoretsky (2007-08-07 13:31:00) [52]
> Сегодня неавтоинкрементное уникальное поле наличествует, завтра не наличествует, послезавтра наличествует неуникальное.

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

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

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

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

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

Игорь Шевченко (2007-08-07 12:08:00) [54]
Sergey13 © (07.08.07 11:56) [38]

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

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

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

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

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

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

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

Игорь Шевченко (2007-08-07 11:53:00) [56]

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

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

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

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

Sergey13 (2007-08-07 11:47:00) [57]
> [35] Игорь Шевченко © (07.08.07 11:41)

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

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

Игорь Шевченко (2007-08-07 11:41:00) [58]
Sergey13 © (07.08.07 11:37) [34]

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

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

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

Игорь Шевченко (2007-08-07 11:35:00) [60]

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

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

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

Наверх

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