Первичный ключ

← →
Mozart © (2006-04-15 20:54) [0]

Вот такой вопрос - есть поля - "ФИО" "Дата рождения" "Телефон", так по какому первичный ключ заводить? Если говорит прямо - только сейчас решил заняться БД, как говориться "конкретно"...

← →
Kerk © (2006-04-15 20:59) [1]

По еще одному, которое autoincrement

← →
Sam Stone © (2006-04-15 20:59) [2]

Создать еще одное поле типа number/integer/еще-какой-циферный и сделать его ключом. Потому что ни одно из этих полей не обеспечит уникальность записи.

← →
Mozart © (2006-04-15 21:05) [3]

Вы имеете ввиду, что то вроде id?

← →
Kerk © (2006-04-15 21:06) [4]

Да

← →
Mozart © (2006-04-15 21:10) [5]

Kerk © (15.04.06 21:06) [4]
Да

Ok, тогда смоделируем ситуацию, когда речь идет о двух филиалах одной фирмы, БД, которых не связаны и самостоятельны, и задача (например) - совместить БД, что тогда?

← →
Kerk © (2006-04-15 21:12) [6]

Я бы составлял ключ из двух частей: id-филиала и уникальное значение сиквенкса.

← →
Mozart © (2006-04-15 21:14) [7]

Т.е. ты хочешь сказать, что id обязательный пункт в любой БД? А не получается громоздкая модель?

← →
Marser © (2006-04-15 21:14) [8]

> [1] Kerk © (15.04.06 20:59)
> По еще одному, которое autoincrement

Кстати, когда-то давно, когда я в БД ещё практически ничего не смыслил, была тут такая точка зрения(причём, у одного из нынешних мастеров), что автинкререментное поле делать ключевым нехорошо. Я так и не понял, почему...

← →
Kerk © (2006-04-15 21:17) [9]

Marser © (15.04.06 21:14) [8]

Оптимально имхо использовать что-то типа [6]. Почему сам по себе автоинкремент плох в общем случае - хз.

Mozart © (15.04.06 21:14) [7]
А не получается громоздкая модель?

С чего бы?

← →
Sam Stone © (2006-04-15 21:22) [10]

>Ok, тогда смоделируем ситуацию, когда речь идет о двух филиалах одной
> фирмы, БД, которых не связаны и самостоятельны, и задача (например) -
>совместить БД, что тогда?
В смысле чтобы косяка из-за одинаковых id записей не было? Сделать апдейт каскадом на совпадающие идентификаторы и после слить ;)

← →
Mozart © (2006-04-15 21:26) [11]

to Sam Stone © (15.04.06 21:22) [10]

ну я ОЧЕНЬ мало смыслю в БД, но, по - моему - так некорректно...:)

to Kerk © (15.04.06 21:17) [9]

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

← →
Desdechado © (2006-04-15 21:28) [12]

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

← →
Sam Stone © (2006-04-15 21:30) [13]

2Mozart
Некорреткности не виду ) разве что коряво ) При каскадном обновлении все внешние ключи поменяются автоматом и юзеры даже не заметят разницы )
А вообще в каждом конкретном случае отдельно надо думать.

← →
Kerk © (2006-04-15 21:31) [14]

Mozart © (15.04.06 21:26) [11]
насчет громоздкости - так ведь два новых поля...

Почему два? Одно.

← →
Mozart © (2006-04-15 21:32) [15]

Ребята - яж не про конкретный проект спрашиваю :), просто ставлю перед собой задачи и пытаюсь их решить, правда с Вашей помощью :)

← →
SergP. (2006-04-15 22:06) [16]

> насчет громоздкости - так ведь два новых поля...

А заводить первичный ключ по ФИО - не громоздко?

← →
Lamer@fools.ua © (2006-04-15 22:11) [17]

По сабджу:
http://www.informix.com.ua/articles/key/key.htm

← →
Mozart © (2006-04-15 22:16) [18]

to SergP. (15.04.06 22:06) [16]
а я и спрашивал - по какому корректно :) из существующих, мне говорили, что id как раз некорректно...Ф:(

← →
xayam © (2006-04-15 22:17) [19]

> Mozart ©

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

← →
sniknik © (2006-04-15 22:18) [20]

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

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

← →
xayam © (2006-04-15 22:19) [21]

> > Mozart ©

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

← →
Marser © (2006-04-15 22:21) [22]

Кстати, а ФИО одним полем это однозначный моветон, такая БД даже на первую нормальную форму не тянет...

← →
Lamer@fools.ua © (2006-04-15 22:23) [23]

>Кстати, а ФИО одним полем это однозначный моветон, такая БД даже на первую нормальную форму не тянет...

Смотря, как это поле "ФИО" потом будет использоваться.

← →
Mozart © (2006-04-15 22:24) [24]

2 xayam © (15.04.06 22:17) [19]

> Mozart ©

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

"Прошу пардона" (с) теорию знаю, я ведь про практику спрашивал...

to sniknik © (15.04.06 22:18) [20]
да я тут просто думаю - если филиалов конторы не 2 и даже не 5, притом, что создавались они задолго до объединения - структуры разные...тогда как?

← →
Marser © (2006-04-15 22:27) [25]

> [23] Lamer@fools.ua © (15.04.06 22:23)
> >Кстати, а ФИО одним полем это однозначный моветон, такая
> БД даже на первую нормальную форму не тянет...
>
> Смотря, как это поле "ФИО" потом будет использоваться.

В общем, да. Если это что-то дополнительное и опциональное, то необязательно. А вот по сабжу выходит, что база всё-таки по людям.

← →
xayam © (2006-04-15 22:28) [26]

> "Прошу пардона" (с) теорию знаю, я ведь про практику спрашивал.
> ..

а это что в разных измерениях находится?

← →
Mozart © (2006-04-15 22:29) [27]

to Marser © (15.04.06 22:27) [25]
ну, допустим, по сотрудникам - а если бы было поле ИНН, по нему можно сделать ключ?

← →
Marser © (2006-04-15 22:31) [28]

> [27] Mozart © (15.04.06 22:29)
> to Marser © (15.04.06 22:27) [25]
> ну, допустим, по сотрудникам - а если бы было поле ИНН,
> по нему можно сделать ключ?

Я извиняюсь за неброзавнность, но что такое ИНН?

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

> если филиалов конторы не 2 и даже не 5
ну значит в "id-филиала" у тебя будут значения не от одного до пяти а больше... до тысячи например. делов то.

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

to Marser © (15.04.06 22:31) [28]
:))) ну индивидуальный номер налогоплательщика - ты, наверное, еще не работаешь, поэтому не знаешь :), но у всех, кто официально устроен есть такая бумажка...

to xayam ©
насчет теории и практики - это уже извечный вопрос - "могут ли научить чему - либу новому в ВУЗ`е"

А почему не делал бы?

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

> А почему не делал бы?

[30]
> "могут ли научить чему - либу новому в ВУЗ`е"
Вузы ничему не учат, это только от тебя зависет

> [32] Mozart © (15.04.06 22:36)
> to Marser © (15.04.06 22:31) [28]
> :))) ну индивидуальный номер налогоплательщика - ты, наверное,
> еще не работаешь, поэтому не знаешь :), но у всех, кто
> официально устроен есть такая бумажка...

Нет, я таки работаю, причем уже три года, но есть два но - слава Богу, не в бухгалтерии и даже не рядом, а во во-вторых - в Украине это называется "Персональний ідентифікаційний номер фізичної особи - платника податків".
Так вот, так, как он формируется у нас - ИМХО, можно делать ключевым. Только ногами не бейте :-)

>>Marser © (15.04.06 22:44) [37]
Да можно, конечно, если имеется в виду его уникальность для каждого человека. Только мне часто встречались задачи, когда уникальности такой не хватает. То есть нужна не уникальность характеристики объекта, а ункальность самой записи. Поэтому взял за правило - проблем меньше.

> Только ногами не бейте :-)

надо бы)) но сначала хотелось узнать как это он у Вас по-особенному формируется

to Marser © (15.04.06 22:44) [37]
"Персональний ідентифікаційний номер фізичної особи - платника податків".

прикольно звучит :)

to Внук © (15.04.06 22:43) [36]

а по ИНН нельзя? или некорректно?

Первичный ключ Найти похожие ветки