Удобно ли использовать?

← →
koha! (2009-11-26 06:28) [0]

Часто в реляционных таблицах используют ключевое поле ввиде счетчика который сам заполлняется например, создали таблицу справосник:

| key | наназвание рибора |

поле key сделали счетчиком

народ скажите:

- всегда ли это уместно?
- использует кто-нибудь другие способы?

← →
Inovet © (2009-11-26 08:37) [1]

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

← →
Sergey13 © (2009-11-26 09:06) [2]

> [0] koha! (26.11.09 06:28)
> - всегда ли это уместно?
Практически всегда. Хоть это и не единственный вариант.

> - использует кто-нибудь другие способы?
Конечно.

ЗЫ: Странный вопрос какой то.

← →
Сергей М. © (2009-11-26 09:34) [3]

> всегда ли это уместно?

Это уместо тогда, когда нет естественного ключа.

> использует кто-нибудь другие способы?

Кто-нибудь обязательно использует.

← →
ANB (2009-11-26 09:40) [4]

> | key | наназвание рибора |

Неправильно.

Надо :
ID - суррогатный ключ
Shifr
Name
. . .
И еще куча полей.

:)

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

← →
Anatoly Podgoretsky © (2009-11-26 10:59) [5]

Удобство - это не тот критерий в данных случаях.

← →
clickmaker © (2009-11-26 11:09) [6]

> всегда ли это уместно?

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

← →
sniknik © (2009-11-26 11:36) [7]

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

> Тогда используют составные или естественные ключи
или все таки искусственный но гарантированно уникальный, гуид например.

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

← →
Григорьев Антон © (2009-11-26 11:52) [8]

Вот тут об этом спорили, спорили да так и не пришли к единому мнению: http://www.delphikingdom.com/asp/talktopic.asp?ID=152 Но всё равно интересно почитать аргументацию обеих сторон.

← →
Игорь Шевченко © (2009-11-26 13:17) [9]

Григорьев Антон © (26.11.09 11:52) [8]

Марксизм не догма, а руководство к действию

← →
Рамиль © (2009-11-26 14:28) [10]

> например, при работе клиента временно в оффлайне, когда
> нет возможности интерактивно сгенерить идентити в базе.

Ну, можно при синхронизации некоторое количество сгенерить про запас или GUID использовать.

> Ну, можно при синхронизации некоторое количество сгенерить
> про запас

если таких клиентов до хрена, то это не спасет
нужна же сквозная уникальность

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

← →
ANB (2009-11-30 09:34) [13]

>
> если таких клиентов до хрена, то это не спасет
> нужна же сквозная уникальность

Клиент СУБД в оффлайн ?
И при этом больше одной мастер записи ?
Не знаю, зачем может понадобиться такой изврат, разве что при смещении объектного и реляционного методов (что само по себе есть извращение).
Но и при этом есть минимум 3 решения :
ГУИД
Сгенерить ИД про запас (не пройдет, если СУБД не имеет генераторов, как у парадокса и мс скл)
Использовать мнемонику, например : положительные ИД - реальные из БД, отрицательные - псевдо ИД на клиенте, затем подлежать замене на реальные при сохранении данных в БД.

> Клиент СУБД в оффлайн ?

лехко. Привет от TClientDataset

> И при этом больше одной мастер записи ?

мастером выступает юзер, он же клиент. На него все накручивается, как спагетти на вилку.
То есть вместо того, чтобы оперировать одним суррогатным идентити, мы имеем дело с ключами типа UserId, OrderId, чего-то там еще Id.
Где OrderId уникален в рамках UserId, а что-то там еще Id - в рамках OrderId

Удобно ли использовать? Найти похожие ветки