| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
UpDate. Как изменить одну запись, если их несколько одинаковых?
DmitrichJ © (2007-08-02 14:18:00)Допустим в базе есть несколько абсолютно одинаковых записей в 2-х полях:
| name | code |
1. | "Вася" | 0 |
2. | "Вася" | 0 |
3. | "Вася" | 0 |
и мне нужно одной, любой из этих записей изменить значение code.
Или всё же нужно создовать идентифицирующее поле np?
Игорь Шевченко (2007-08-07 11:32:00) [61]Sergey13 © (06.08.07 10:52) [22]
> ИК обычно генерится без участия человека, а ЕК наоборот
> обычно вводится оператором. Введя корректный, но неправильный
> ЕК, можно теоретически огрести немного неприятностей.
> Я всегда вставляю ИК, даже при наличии стойкого ЕК. При
> этом ЕК очень удобно юзать для поиска, а ИК для связей.
Ты мазохист
MsGuns © (06.08.07 12:02) [23]
> За редким исключением рекомендую использовать в качестве
> ПК уникальный идентификатор (автоинремент,генератор, последовательность.
> .) - преимуществ масса: от скорости выборок до мобильности
> данных в таблицах (независимость ХРАНЕНИЯ данных от их СОДЕРЖАНИЯ)
А вот Joe Celko не рекомендует. Кому из вас верить ?
Насчет скорости выборок - давай не надо. Я тебе могу поведать печальную сагу о разработчике, использующем ID везде, в результате, чтобы получить приемлемую выборку, ему часто приходится соединять 8-10 таблиц в запросе.
Виталий Панасенко(дом) (2007-08-07 01:12:00) [62]
> Fredy314 © (07.08.07 00:08) [30]
>
> LIMIT 1; попробуй в конце добавить
>
и при этом установить MySQL?...:-\
Fredy314 (2007-08-07 00:08:00) [63]LIMIT 1; попробуй в конце добавить
TMegaMaster(Lamer) (2007-08-06 16:16:00) [64]Все вы говорите верно, есть еще и фактор удобства для программирования. Когда вы знаете, что в любой таблице ПК - это поле ID, Вам гораздо проще сделать универсальный механизм доступа к данным. Про построение распределенной БД говорить даже не надо - там даже исключение, описанное
> MsGuns © (06.08.07 14:17) [28]
работать не будет.
MsGuns (2007-08-06 14:17:00) [65]>Jeer © (06.08.07 12:28) [25]
>У меня даже исключений для применения ЕК не находилось до сих пор.
"Перекрестные" справочники для поддержки отношений "многие-ко-многим", которые содержат во всех полях ссылки на другие таблицы. Дублирование записей исключено по определению.
Хотя, конечно, можно и туда запихать ИК, но он там будет явно лишний, т.к. поиска по нему не будет
Sergey13 (2007-08-06 13:05:00) [66]> [24] Anatoly Podgoretsky © (06.08.07 12:27)
> А вот что дополнительно неприятного получишь, так это что
> тебе придется самому поддерживать каскадную целостность
> при апдейте
Я ж говорю, что для связей использую только ИК (для них собственно он у меня избыточно и вводится). Так что как раз тут все нормально. Вот если для связей использован ЕК, тогда да, там где каскадного апдейта нет - придется покорпеть в случае замены в ПК.
Anatoly Podgoretsky (2007-08-06 12:32:00) [67]> Jeer (06.08.2007 12:28:25) [25]
По статистике, более 99% ключей искуственные, и где надо и где не надо.
Jeer (2007-08-06 12:28:00) [68]
> За редким исключением
У меня даже исключений для применения ЕК не находилось до сих пор.
Anatoly Podgoretsky (2007-08-06 12:27:00) [69]Sergey13 © (06.08.07 10:52) [22]
По приведеному тобой примеру обретешь теже самые проблемы, просто это будет не в первичном ключе, а в поле, к тому же избыточность, второе поле тоже придется делать уникальным и оно по сути будет дублировать ключ, отличаясь только информацией в поле.
А вот что дополнительно неприятного получишь, так это что тебе придется самому поддерживать каскадную целостность при апдейте, либо запросом, либо триггерами, но придется. А в случае выбора в качестве кандидата на первичной ключ, этой работой мог бы заниматься сервер, гарантируя целостность базы. Естественно относится только к тем сервервам, которые поддерживают Cascade Update/
Ну а преимущества ИК указаны в MsGuns © (06.08.07 12:02) [23]
MsGuns (2007-08-06 12:02:00) [70]За редким исключением рекомендую использовать в качестве ПК уникальный идентификатор (автоинремент,генератор, последовательность..) - преимуществ масса: от скорости выборок до мобильности данных в таблицах (независимость ХРАНЕНИЯ данных от их СОДЕРЖАНИЯ)
Sergey13 (2007-08-06 10:52:00) [71]> [21] Anatoly Podgoretsky © (06.08.07 10:42)
> никакой это защиты не дает.
Ну, защитой это конечно можно назвать только со смайликом, но все таки. ИК обычно генерится без участия человека, а ЕК наоборот обычно вводится оператором. Введя корректный, но неправильный ЕК, можно теоретически огрести немного неприятностей.
Я всегда вставляю ИК, даже при наличии стойкого ЕК. При этом ЕК очень удобно юзать для поиска, а ИК для связей.
Я не спорю, что это дело вкуса и иногда напоминает религиозность. Я хотел сказать, что это не приности явного вреда, на мой взгляд. А выгода - хотя бы чувство уверенности в завтрашнем дне. 8-)
Anatoly Podgoretsky (2007-08-06 10:42:00) [72]
> Sergey13 © (06.08.07 10:10) [19]
Как раз наоборот, никакой это защиты не дает.
Все должно быть в меру.
Одно не вызывает сомнения, что должен быть первичный ключ. А какой дело или религии или конкретной задачи. У ЕК и ИК ключей есть свои достоинства и недостатки. Я использую оба типа ключей. Там где на задачу нормально накладывается ЕК то используется он.
Jeer (2007-08-06 10:34:00) [73]Действительно, оставим в стороне вопрос о ПК и ЕК, излишествах..
Но, если в таблице одно поле NAME и нет unique индекса, то отличать одну запись от другой при совпадении значений в NAME можно будет только по физическому номеру записи, что уже полный бред.
Sergey13 (2007-08-06 10:10:00) [74]> [17] Anatoly Podgoretsky © (06.08.07 10:04)
Излишность в данном конкретном случае, ИМХО, можно обозвать, например, дополнительной степенью защиты от человеческого фактора. 8-)
Кщд (2007-08-06 10:07:00) [75]>Sergey13 © (06.08.07 09:08) [15]
лично мне ближе позиция монаха уильяма))
>MsGuns © (06.08.07 09:43) [16]
перед тем, как перейти дорогу: смотрю налево, смотрю направо
даже если дорога пуста
казалось бы, какое это имеет отношение к проектированию баз данных?))
уважаемые коллеги, ни в коем случае не пытался изменить чей-то сложившийся (проверенный опытом, доказавший свою эффективность и т.д.) подход
всего лишь выразил легкое недоумение категоричным советом
и только
желания похоливорить не было
Anatoly Podgoretsky (2007-08-06 10:04:00) [76]Может и вредить, например излишностью.
MsGuns (2007-08-06 09:43:00) [77]>Кщд © (06.08.07 08:57) [14]
>а "создавай поле ID ВСЕГДА тчк" - это религия, не находите?)
Один мой друг, автомобилист, когда едет, всегда поглядывает в зеркало заднего обзора. Даже если шоссе пустынно.
Он религиозный фанат ?
Sergey13 (2007-08-06 09:08:00) [78]> [14] Кщд © (06.08.07 08:57)
Это как чистить зубы - полезная привычка, которая, как минимум, не вредит. 8-)
Кщд (2007-08-06 08:57:00) [79]>Sergey13 © (03.08.07 15:05) [10]
естественные против суррогатных, принципиальная необходимость первичных или наоборот и т.д. - это специфика задачи и богатство опыта))
а "создавай поле ID ВСЕГДА тчк" - это религия, не находите?)
TMegaMaster(Lamer) (2007-08-03 18:08:00) [80]
> Кщд © (03.08.07 14:48) [9]
> >TMegaMaster(Lamer) (02.08.07 19:56) [8]
> мозги не пудрили бы бодаванам юным догмой религиозной))
Всего лишь хочу помочь обойти грабли на которые сам наступал неоднократно. Извечный спор про естественные ПК против искусственных - мимо. Углубляться не буду, но выполнение упомянутого принципа нетрудоемко, но позволяет в дальнейшем только радоваться полному контролю над системой.
| |
Страницы: 