Code&ID

[vavkin]

Цитата:

Сообщение от George Nordic

Хм. А при переносе данных Вы сможете таким механизмом гарантировать целостность данных?

Если имеется ввиду полный перенос то да, при переносе не обязательно сразу пользоваться autoincrement, можно вначале просто копировать данные а потом включить уже включить autoincrement. Если имеется ввиду объединение баз то int могут совпасть ровно с таким же успехом как и Code. И у Code здесь нет преимуществ.
И вообще почему бы не использовать uniqueidentifier (GUID)

[George Nordic]

Цитата:

Сообщение от vavkin

Если имеется ввиду объединение баз то int могут совпасть ровно с таким же успехом как и Code. И у Code здесь нет преимуществ.
И вообще почему бы не использовать uniqueidentifier (GUID)

Вам же сказали:
-Упрощение сопровождения
-Уменьшение размера БД
-Увеличение скорости выборки данных
-Увеличение скорости обновления данных
-В системе с ЕК меньше JOIN`ов, следовательно, запросы проще и разработка удобнее
-Введение СК нарушает третью нормальную форму
-Таблицы в системе с ЕК информативнее

Если есть контрпримереры - давай поспорим. Действительно, есть спорные моменты.
Ведь, как я понимаю, это чисто теоритический спор? Или Вы планируете использоватть GUIN в качестве ключа при разработке собственных таблиц?
Лично мне нравится в виде ключа видеть "МИ-АКС-НОГ(40) 100х20", чем 123579 или 1657-AB10-C548F-4564-BD20

С Уважением,
Георгий.

[vavkin]

Цитата:

Сообщение от George Nordic

-Упрощение сопровождения
-Уменьшение размера БД
-Увеличение скорости выборки данных
-Увеличение скорости обновления данных
-В системе с ЕК меньше JOIN`ов, следовательно, запросы проще и разработка удобнее
-Введение СК нарушает третью нормальную форму
-Таблицы в системе с ЕК информативнее

Если есть контрпримереры - давай поспорим. Действительно, есть спорные моменты.
Ведь, как я понимаю, это чисто теоритический спор? Или Вы планируете использоватть GUIN в качестве ключа при разработке собственных таблиц?
Лично мне нравится в виде ключа видеть "МИ-АКС-НОГ(40) 100х20", чем 123579 или 1657-AB10-C548F-4564-BD20

Это не теоретический спор. Практический, и для меня даже очень.
Теперь по пунктам.
"Упрощение сопровождения" - не вижу никаких преимуществ одного перед другим.
"Уменьшение размера БД" - за счет чего она уменьшится? если использовать int то при code размер будет больше, если GUID который 16 символов то тоже меньше чем если Code который 20, я могу ошибиться в кол-ве символов, да на самом деле не так уж это важно, будет на 2 % больше размер или меньше. У этого пункта нет преимуществ, точнее по этому пункту Code проигрывает
"Увеличение скорости выборки данных" за счет чего? При выводе связанной информации int по крайней мере не медленнее чем Code и я сильно сомневаюсь что GUID медленне чем Code. По этому пункту Code выигрывает только в том случае если он сам по себе достаточен и не нужен join, как только появляется связь (а она появится) то Code не выигрвает а скорее проигрывает.
"Увеличение скорости обновления данных" честно говоря вообще не понятно за счет чего, можно поподробнее?
"В системе с ЕК меньше JOIN`ов, следовательно, запросы проще и разработка удобнее" проще только разработка форм и то в том случае когда опять же коды самодостаточны. При разработке модификации как таковой вообще не вижу преимуществ у Code, ведь значения кодов не сипользуются в тексте модификации и значит мне как программеру все равно что там в нем ID или Code. В системе с ЕК меньше join'ов только при выводе формы, в отчетах все равно надо связываться со связынными таблицами.
"Введение СК нарушает третью нормальную форму" каким образом?
"Таблицы в системе с ЕК информативнее" они информативнее только в том случае если их смотреть через Enterprise manager, но как правило их смотрят через систему и система могла бы сама выполнить автоматически join и тогда пользователю становится все равно как хранятся данные внутри.
"Или Вы планируете использоватть GUIN в качестве ключа при разработке собственных таблиц?" По крайней мере вижу причин не использовать их
"Лично мне нравится в виде ключа видеть "МИ-АКС-НОГ(40) 100х20", чем 123579 или 1657-AB10-C548F-4564-BD20" это относится к информативности и я уже высказался выше.