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]

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

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

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

Sergey13 © (06.08.07 10:52) [22]

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

Ты мазохист

MsGuns © (06.08.07 12:02) [23]

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

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

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

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

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

Sergey13 © (07.08.07 11:37) [34]

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

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

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

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

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

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

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

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

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

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

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

Sergey13 © (07.08.07 11:56) [38]

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

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

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

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

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

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

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

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