|
|
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Хотелось бы услышать аргументы о том, насколько плохо и плохо ли вообще делать primary key не числовым. Допустим, есть сущность. В моем случае это филиал банка. Я знаю наверняка что у филиала есть четырехсимвольный id. Например 0000 или 0001. Что мне мешает сделать char(4) и сделать его primary key? Какие у этого решения минусы? Меня всегда напрягало создание дополнительного "ненужного" id, когда есть уникальное поле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 15:29 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
а меня не напрягает но я не против вашей мысли лишь бы уникальное не перестало быть таковым однажды С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 15:35 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Вопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 15:37 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным.возможно да, например для таблиц служащих отношением многие-ко-многим но и такие таблицы могут "превратится в сущности", но редко ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 15:41 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Nafа меня не напрягает но я не против вашей мысли лишь бы уникальное не перестало быть таковым однажды С уважением, Naf В таком случае в качестве ID можно взять то, что на текущий момент в таблице объявлено unique, а id вообще выкинуть. Аргументы против? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 15:45 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am IХотелось бы услышать аргументы о том, насколько плохо и плохо ли вообще делать primary key не числовым. Допустим, есть сущность. В моем случае это филиал банка. Я знаю наверняка что у филиала есть четырехсимвольный id. Например 0000 или 0001. Что мне мешает сделать char(4) и сделать его primary key? Какие у этого решения минусы? Меня всегда напрягало создание дополнительного "ненужного" id, когда есть уникальное поле. CHAR(4) - ничего не мешает, VARCHAR(255) - мешает то что это огромное поле придется везде за собой таскать. В таблице многие ко многим PKем и является (id_entity1, id_entity2), ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 16:20 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am INafа меня не напрягает но я не против вашей мысли лишь бы уникальное не перестало быть таковым однажды С уважением, Naf В таком случае в качестве ID можно взять то, что на текущий момент в таблице объявлено unique, а id вообще выкинуть. Аргументы против?как и говорил, может стать однажды не уникальным или измениться, от ситуации зависит это известный спор Естественные и суррогатные ключи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 16:24 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Нужно понимать, что зачастую БД не является первичным регистром, а лишь отражает состояние некой внешней системы, в которой могут быть исключения из правил. А PK не терпит никаких исключений. В объектных БД каждая запись в БД имеет уникальный ID объекта независимо от наличия PK на таблице. Это современная тенденция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 16:29 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным.Бессмысленно платить зарплату таким горе-архитекторам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 17:05 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
LSVWho am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным.Бессмысленно платить зарплату таким горе-архитекторам Отличный аргумент, только бесполезный. Максимум что вы здесь сделали, это попытку поднять свое эго за счет принижений качеств другого человека. =) Может быть все же вернемся к конструктивному разговору? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 17:26 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Если бы PK был обязательным, в запросе CREATE TABLE вам бы пришлось всегда указывать PK. Если PK не нужен, не делай его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 17:47 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
использовую UUID. Вполне себе хороший идентификатор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 17:58 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am I wrote: > Хотелось бы услышать аргументы о том, насколько плохо и плохо ли вообще > делать primary key не числовым. Ни плохо, и ни хорошо. Равнозначно с числовыми идентификаторами. На самом деле пофигу, какой идентификатор, главное, чтобы он был уникальными. (специфики конкретных СУБД тут мы не рассматриваем). > Какие у этого решения минусы? по большому счёту, никаких. > Меня всегда напрягало создание дополнительного "ненужного" id, когда > есть уникальное поле. В общем, правильно напрягало, если конечно это ДЕЙСТВИТЕЛЬНО уникальное поле. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 20:28 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
> насколько плохо и плохо ли вообще делать primary key не числовым. Теоретически тип данных не играет роли. Практически - компактнее и проще оперировать числами. > Я знаю наверняка что у филиала есть четырехсимвольный id. Типичная ошибка. Вы можете что-то знать только о данных, источник которых контролируете. Если где-то в какой-то другой базе данных некие данные имеют какой-то идентификатор, то в своей базе данных вы можете использовать этот идентификатор только и исключительно в виде <источник данных>...<идентификатор экземпляра>...<дата регистрации>. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 21:05 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am IАргументы против? унифицировав имя pk и введя его в ранг обязательных в любых таблицах, вы облегчаете вашим последователям понимание вашего кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 21:55 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
да, и при написании запросов не надо думать "а с чем связать?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 21:56 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am IЯ знаю наверняка что у филиала есть четырехсимвольный id. Например 0000 или 0001. сегодня это так, но где гарантия что так же будет и завтра? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 21:57 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕНиспользовую UUID. Вполне себе хороший идентификатор. Вот чтобы я не делала точно - так это назначала GUID (UUID) ключом в VLDB. На одной колоночке в 6,000,000++ строк только ключ занял 650 GB.... а мог быть всего 150 GB.... Дорого... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:03 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Vika VinnerВот чтобы я не делала точно - так это назначала GUID (UUID) ключом в VLDB. На одной колоночке в 6,000,000++ строк только ключ занял 650 GB.... а мог быть всего 150 GB.... Дорого... можно узнать формулу, по которой считали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:14 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNoseможно узнать формулу, по которой считали? Что - деньги или поле-размер? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:17 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Vika VinnereNoseможно узнать формулу, по которой считали? Что - деньги или поле-размер? :) вот это: GUID (UUID) ключ на одной колоночке в 6,000,000++ строк только занял 650 GB ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:31 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Коллега, снимите свой вопрос... Не к лицу.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:41 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Vika Vinner, "++" - это еще два раза по "000"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:47 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
нет это ещё десять баз данных куда это всё реплицировалось ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:49 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
697,932,185,600/16 = 43,620,761,600 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 22:51 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am IВопрос с ходу: всегда ли нужен primary key? Да. Who am I Я видел ситуации, когда наличие pk в таблице было просто бессмысленным. Можно привести пример таких ситуаций ? Я видел в своей практике только один случай, когда не нужен был первичный ключ - в таблице, которая была предназначена для временного хранения данных, поступавших из внешней системы для хранения в БД. Данные из этой таблицы приводились потом в порядок и записывались в БД. Эти данные из внешней системы были плохого качества (дублированные), поэтому первичный ключ в этой ситуации был не нужен. А какие ситуации были у вас ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 00:12 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Vika Vinner Вот чтобы я не делала точно - так это назначала GUID (UUID) ключом в VLDB. На одной колоночке в 6,000,000++ строк только ключ занял 650 GB.... а мог быть всего 150 GB.... Дорого... Integer занимает на 32 разрядных системах - 32 бита, на 64 разрядных - 64 бита. Guid занимает 128 бит. Считаем на 6 млн строк при использовании Guid у нас уходит 768000000 бит или 96000000 байт~91 мб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 09:09 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным. Ну некоторые программы ( MS Access например ) просто отказываются работать с таблицами без primary key. Это вообще один из основных принципов теории реляционных баз данных. А вообще топикстартера должны уволить за нелояльность, поскольку он не верит что банк где он работает сможет вырасти и иметь больше 10000 филиалов ( это только один пример почему такой ключ может привести к проблемам :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 10:27 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
пролетевшийWho am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным. Ну некоторые программы ( MS Access например ) просто отказываются работать с таблицами без primary key. Это вообще один из основных принципов теории реляционных баз данных. А вообще топикстартера должны уволить за нелояльность, поскольку он не верит что банк где он работает сможет вырасти и иметь больше 10000 филиалов ( это только один пример почему такой ключ может привести к проблемам :-) Для таких таблиц, как банки индексы не нужны.Они будут давать только лишние тормоза ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 11:12 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
пролетевшийА вообще топикстартера должны уволить за нелояльность, поскольку он не верит что банк где он работает сможет вырасти и иметь больше 10000 филиалов ( это только один пример почему такой ключ может привести к проблемам :-) Его хоть за лояльность, а вас, по видимому, за недостаток знаний? :) CHAR(4) - в худшем случае 4 байта. В лучшем 8, а то и больше байт. Сколько в них разных комбинацией поместится сами посчитаете? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 12:15 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Vika VinnerОКТОГЕНиспользовую UUID. Вполне себе хороший идентификатор. Вот чтобы я не делала точно - так это назначала GUID (UUID) ключом в VLDB. На одной колоночке в 6,000,000++ строк только ключ занял 650 GB.... а мог быть всего 150 GB.... Дорого... 6,000,000 * 16 байт = 96000000 байт ~ 91 мегабайт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 13:46 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
SeVaпролетевшийWho am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным. Ну некоторые программы ( MS Access например ) просто отказываются работать с таблицами без primary key. Это вообще один из основных принципов теории реляционных баз данных. А вообще топикстартера должны уволить за нелояльность, поскольку он не верит что банк где он работает сможет вырасти и иметь больше 10000 филиалов ( это только один пример почему такой ключ может привести к проблемам :-) Для таких таблиц, как банки индексы не нужны.Они будут давать только лишние тормозаа индексы-то тут причём? разговор про первичный ключ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 14:28 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
egorychSeVaпролетевшийWho am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным. Ну некоторые программы ( MS Access например ) просто отказываются работать с таблицами без primary key. Это вообще один из основных принципов теории реляционных баз данных. А вообще топикстартера должны уволить за нелояльность, поскольку он не верит что банк где он работает сможет вырасти и иметь больше 10000 филиалов ( это только один пример почему такой ключ может привести к проблемам :-) Для таких таблиц, как банки индексы не нужны.Они будут давать только лишние тормозаа индексы-то тут причём? разговор про первичный ключ А, что первичный ключ индексом не является? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 14:47 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
> А, что первичный ключ индексом не является? Нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 15:42 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Формально - contraint, но уникальность достигается за счет автоматического создания индекса(по крайней мере, для MS SQL). Вопрос был поставлен не совсем точно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 17:59 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
> по крайней мере, для MS SQL Нет смысла рассматривать диалекты. Оперируйте стандартами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 18:33 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
alexs0ffInteger занимает на 32 разрядных системах - 32 бита, на 64 разрядных - 64 бита. Guid занимает 128 бит. Считаем на 6 млн строк при использовании Guid у нас уходит 768000000 бит или 96000000 байт~91 мб. ОКТОГЕН6,000,000 * 16 байт = 96000000 байт ~ 91 мегабайт. ну, заклевали девушку... Вика, я извиняюсь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 18:39 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
guest_20040621> А, что первичный ключ индексом не является? Нет. является. но "as is", без дополнительных расходов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 18:41 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
> является. но "as is", без дополнительных расходов. Отослать к букварям? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 19:20 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
guest_20040621> является. но "as is", без дополнительных расходов. Отослать к букварям? нет, показать РЕАЛЬНУЮ субд, где праймари ки не является индесом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 19:27 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNoseВика, я извиняюсь! Коллеги, ключевым словом было VLDB если не было Сразу очевидным. Считать мега - кило - гига - это в принципе конечно хорошо. И никто - обратите внимание - никто не посчитал сколько такой же объект возьмёт будь он интеджер. ... И сравнить отношение. Если таких табличек пару килов на распределённой системе ... И диски на которых они стоят Tier I - там и получится $$$$$... В общем нехорошо если разработчики не обратили внимания на такую мелочь своевременно.. Предлагала же вопрос снять ... С самого начала Цифирьки были мои весьма условные... Так для сведения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 19:43 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Vika Vinner, Вика, вот ненадо :) Вери лардж дэйтабэйз на то и "вери лардж", что заранее известны порядки количества строк. Если нет специального ограничения по ресурсам (а это редкость при очень больших объемах), то int64 даёт таки преемущества. Да, размер int64 больше GUID(UUID), но и диапазон по-более. Есть резерв для непредвиденного роста объемов. А еще надо учитывать что INT (и его вариации) - сами по себе ключи, ненадо всяких суррогатов в виде хэшей (как в string-ориентированных ключах) и еще (самое главное) - GUID всё-таки вероятностный ключ... Вероятность мала, конечно, но ... она есть! И если база реплицируется без учета этого то возможна коллизия... вроде не должны были, а они совпали. Парадокс? нет. особенности гуида. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 19:54 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNoseguest_20040621> является. но "as is", без дополнительных расходов. Отослать к букварям? нет, показать РЕАЛЬНУЮ субд, где праймари ки не является индесом.А действительно, есть ли СУБД, в которых PK != индекс? А если есть - почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:03 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNoseVika Vinner, Вика, вот ненадо :) Вери лардж дэйтабэйз на то и "вери лардж", что заранее известны порядки количества строк. Если нет специального ограничения по ресурсам (а это редкость при очень больших объемах), то int64 даёт таки преемущества. Да, размер int64 больше GUID(UUID), но и диапазон по-более. Есть резерв для непредвиденного роста объемов. А еще надо учитывать что INT (и его вариации) - сами по себе ключи, ненадо всяких суррогатов в виде хэшей (как в string-ориентированных ключах) и еще (самое главное) - GUID всё-таки вероятностный ключ... Вероятность мала, конечно, но ... она есть! И если база реплицируется без учета этого то возможна коллизия... вроде не должны были, а они совпали. Парадокс? нет. особенности гуида. Есть различные методы выработки. Есть вероятностный, а естьпо mac адресам+ время + соль. Если в системе совпадают эти адреса, это проблемы того, кто пользуется дешёвым китайским оборудованием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:04 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Senya_LА действительно, есть ли СУБД, в которых PK != индекс? есть :) БерклиДБ (в оригинале). Senya_LА если есть - почему? Потому что такова изначальная идеология: пара индекс-хэш. Но это не для guest_20040621, он пусть сам думает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:08 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕНЕсть различные методы выработки. Есть вероятностный, а естьпо mac адресам+ время + соль. Если в системе совпадают эти адреса, это проблемы того, кто пользуется дешёвым китайским оборудованием. так всё дело в том, то гуиды не гарантируют уникальность вообще. в определении честно указано, то "вероятность совпадения мала", но она всё-таки есть. как я это понимаю, чем больше объем таблицы (в строках) - тем больше вероятность напороться на дубль (в пределах одной железки врядли, но если идет репликация с нескольких серверов...). и уж тем более, если заранее известно, что база - vldb - то использовать гуиды опасно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:13 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNoseДа, размер int64 больше GUID(UUID), но и диапазон по-более. Есть резерв для непредвиденного роста объемов. это не читать, это я пиво пью :) стормозил :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:22 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNoseесть :) БерклиДБ (в оригинале).Надо же... Поверю на слово, хотя это как-то иррационально. Хотя, может быть и ближе к "чистой науке" :) eNoseeNoseДа, размер int64 больше GUID(UUID), но и диапазон по-более. Есть резерв для непредвиденного роста объемов. это не читать, это я пиво пью :) стормозил :)А я вже начал сомневаться в адекватности восприятия. И не напрасно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:36 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNose, Если в системе совпадают эти адреса, это проблемы того, кто пользуется дешёвым китайским оборудованием. Вы читать умеете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:48 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕНeNose, Если в системе совпадают эти адреса, это проблемы того, кто пользуется дешёвым китайским оборудованием. Вы читать умеете? авторИ если база реплицируется без учета этого то возможна коллизия... умею. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:51 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, мак-адрес сужает диапазон уникальных адресов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:53 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕН, и это ... мак-адрес - это 48 (иногда 64) бита. так что уникальность как бы ограничена. причем в случае 64-х битного она такая же, как и у int64. и это несмотря на то что GUID весит 128 бит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:59 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
> нет, показать РЕАЛЬНУЮ субд, где праймари ки не является индесом Я не знаю таких СУБД. И? Расскажите, где в стандарте упоминаются неявные индексы и формулируются требования к ним. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 21:54 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
eNose, ну если вам мало 18446744073709551616 строк в пределах одного сервера, то я не знаю что и предложить. Вы можете использовать тип NUMERIC без ограничений на точность. В PostgreSQL таковой имеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 22:52 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕНeNose, ну если вам мало 18446744073709551616 строк в пределах одного сервера, то я не знаю что и предложить. Вы можете использовать тип NUMERIC без ограничений на точность. В PostgreSQL таковой имеется. Проверил, 510 значное число вполне себе сохраняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 23:06 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Flying DutchmanWho am IВопрос с ходу: всегда ли нужен primary key? Да. В реляционной модели данных PK нужны, в противном случае будет невозможно применять теорию реляционных БД. Но в реализации создавать ограничение целостности PK может быть и не нужно (уникальность ключа обеспечивает другой механизм) или нельзя (индекс слишком большой, тормозит операции вставки записей, в запросах не используется, а нарушение целостности, если оно возможно, некритично или может быть исключено иными средствами). Короче, разделяйте теоретическую модель и техническую реализацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 19:12 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
ОКТОГЕНОКТОГЕНeNose, ну если вам мало 18446744073709551616 строк в пределах одного сервера, то я не знаю что и предложить. Вы можете использовать тип NUMERIC без ограничений на точность. В PostgreSQL таковой имеется. Проверил, 510 значное число вполне себе сохраняется. Да вы посчитайте, сколько времени уйдёт на вставку такого колиества записей. Полагаю вопрос про запас отпадёт сам собой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 19:13 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
mcureenab, да я-то понимаю. Просто зачем выдумывать проблемы там, где их нет. Мало какая база содержит миллиардные таблицы(предел некоторые SQL серверов, между прочим). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2009, 00:16 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Ещё добавлю... Немаловажно время и сложность генерации ключа. Если целое число, это грубо говоря i++ (плюс блокировка разделяемого ресурса и время от времени сохранение в БД), то GUID вычисяется сложнее. Вероятная неуникальность в пределах одной БД разрешается на уровне PK - если с новым GUID PK нарушается, ну создаём новый GUID. В оракле GUID широко используются для генерации Type ID и Object ID. Причём даже в распределённых БД я не слыхал о проблемах связанных с совпадением GUID во время репликации, но и в VLDB я бы их использовать не стал. Расчитывать на использование всего множества значений MAC адресов или GUID не приходится. Часть значений либо остануться навсегда зарезервированными (как например коды производителей в MAC адресах), часть будет безвозвратно потеряна (если в алгоритме GUID используется время). Если биться за каждый бит, то наверное самым лучшим отношением мощности множества значений на байт обладает тип RAW, но не везде есть быстрый генератор RAW ключей. PK как правило используются для поиска записей и индексируются. Сравнение длинных ключей во время поска идёт чуток дольше. Индекс с длинным ключём занимает больше места в БД и в кэше. Но всё это дело десятое . Если реализация БД будет сильно отличаться от модели, расходы на её сопровождение быстро превысят экономию на дисках. Сейчас терабайтным диском или многотерабайтным RAID'ом в домашнем ПК мало кого удивишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2009, 04:31 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Who am ILSVWho am IВопрос с ходу: всегда ли нужен primary key? Я видел ситуации, когда наличие pk в таблице было просто бессмысленным.Бессмысленно платить зарплату таким горе-архитекторам Отличный аргумент, только бесполезный.Он бесполезный для тех, кто не знает второй нормальной формы. Нафига нужна запись, которую невозможно однозначно идентифицировать (нет уникального признака) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2009, 12:21 |
|
||
|
Primary key не integer
|
|||
|---|---|---|---|
|
#18+
Реляционная алгебра оперирует множествами, а множество это набор уникальных элементов. Если мы говорим о реляционном отношении, то подразумеваем, что у него есть PK. В противном случае это не отношение. ER моделирование и тем более функциональная декомпозиция оперируют отношениями. В объектных БД каждый объект идентифицируем и не обязан иметь PK. Создавать PK в БД не обязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2009, 16:33 |
|
||
|
|
start [/forum/topic.php?all=1&fid=32&tid=1542924]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
160ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
111ms |
get tp. blocked users: |
2ms |
| others: | 217ms |
| total: | 540ms |
| 0 / 0 |
