|
|
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Господа! Помогите решить спор. Мой PM сам создал базу. При этом там имеется две таблицы - ADDRESSES и COMPANY_ADDRESSES. Он хочет, чтоб в таблице ADDRESSES поля COUNTRY,STREET, HOUSENUMBER составляли Primary Key. При этом в таблице COMPANY_ADDRESSES есть 3 таких же поля, которые являются FK на таблицу ADDRESSES. Я предложил сделать ID суррогатным и эти три поля уникальными. Но на вопрос, в чем преимущество такого подхода, я ответил только, что проще делать мэппинг в Hibernate. Тогда он согласился так сделать (с ID и тремя уникальными полями), но при этом оставил такие же 3 поля (COUNTRY,STREET, HOUSENUMBER) и в таблице COMPANY_ADDRESSES. И агументировал тем, что если понадобиться прочитать эти поля для COMPANY_ADDRESSES, то Oracle не будет обьединять эти 2 таблицы по ADDRESSES.ID, а просто прочитает их из COMPANY_ADDRESSES. Честно говоря, я не видел раньше такого и кажется дублировать поля в 2 таблицах неразумно. Решил посоветоваться - может я неправ. И вот вопросы 1) В чем преимущества суррогатного ключа? 2) Ускоряет ли дублирование полей в нескольких таблицах быстродействие базы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2007, 15:20:26 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
PM это Project Manager? А с чего это он создает базу? Хотя при вашем уровне, похоже, это оправдано, раз возникают такие глупые прямо скажем споры. Читать о нормальных формах БД, пока не наступит просветление. У вас не тот случай, чтобы поступиться принципами нормализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2007, 19:53:17 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Переименовывались: Страны: Бирма -> Мьянма, Берег слоновой кости -> Кот Дивуар, ГДР -> ФРГ ... Города: Горький -> Н.Новгород, Калинин -> Тверь, Киров -> Вятка, Рыбинск -> Андропов -> Рыбинск ... Улицы: просто дофиг в каждом городе Оно вам надо - после такого переименования отслеживать двусмысленности в ключах? Юзайте суррогатный PK и не парьтесь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2007, 23:12:16 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
ХМ.... Странно видеть вопрос по архитекруре базы на форуме по java.... Хотя, если по существу вопроса... Лучше использовать конечно-же суррогатный ключ в качестве РК. Кроме того, нормализацию баз данных - ещё никто не отменял. И что это за проблема для ораклового сервера соединить две таблицы? В общем - учтать матчасть... А такого глупого РМ - за парту на курсы по базам данных... Шутка.. Просто ещё новогоднее настроение. PS. Я, если чесно, и сам РМ, но до такого ещё пока не додумался :-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2007, 06:47:55 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2007, 11:13:58 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Но в каких случаях надо поступаться нормализацией базы. Только что имел с ним тим толкинг по скайпу. Вообще ничего не понимаю. Например - таблица Persons и таблица Decisions. В обеих есть поле Username. Значит человек логиниться - в это время в HTTP сессии запоминается его USERNAME(а не ID из таблицы Persons) и когда этот юзер отправляет запись в таблицу Decisions, то в поле Decisions.Username записывается эта строка. Я говорю, зачем нам в нескольких таблицах хранить этот Username - достаточно в HTTP сессии сохранить ID залогинившегося юзера. А он грит - так будет быстрее. Есть ли такая практика, чтоб хранить одно и тоже поле в нескольких таблицах для скорости? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2007, 11:20:25 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Ну что сказать про такое? Можно только Вам посочуствовать, хотя если РМ из инстранщины - тогда понятно :-) Кстати по поводу хранения имени пользователя в разных таблицах. Можно конечно и так, вот только здесь нужно задуматься о том, что к примеру тогда возрастает объём данных и снижается скорость запросов, т.к. число для сервера БД зачастую "весит" меньше чем символьные строки. И кстати ключи по числовым данным обычно работают быстрее чем по символьным, т.к. математика при этом работает быстрее. Кроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня. Но это моё ИМХО и обсуждать его не буду, скажу лишь, что например тот же Oracle в своём Collaboration Suite информацию о том, кто создатель объекта, кто его изменятель хранит как числовое значение ключа (ID), а не символьную строку. И при этом всё нормально работает и летает. Но это так к слову. Так что думаю Вам ещё не раз предстоит ломать копья со своим РМ-ом по этому поводу. А вот мне интересно, кто у Вас занимается архитектурой системы и базы, есть для этого отдельный человек в команде или нет? ________________________________________________________ Всегда есть куда развиваться, нужно просто этого хотеть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2007, 17:53:37 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
И ещё одна мысль... oson... А он грит - так будет быстрее... Допустим, это будет быстрее при записи, а также при селекте из таблицы решений и только из неё. Но вот если вдруг необходимо будет посмотреть, а кто-же на самом деле этот пользователь USER12345, то есть, узнать его личные данные, то тут уже всё равно придётся лезть в таблицу где эти данные хранятся. А если это ещё нужно будет делать в виде отчёта и с группировкой по каждому пользователю, то тогда по любому нужно будет делать JOIN по полям. Ну а дальше думаю можно подумать о производительности... И ещё момент, к примеру человек захотел изменить своё имя пользователя, что тогда? Обновлять все его записи во всех таблицах, где есть имя пользователя на новое имя, для сохранения истории? Тоже смысла особого не видно... PS. Сразу обращусь к тем, кто захочет меня попинать на почве ключей и производительности - отвечать не буду. Т.к. это моё личное мнение, основанное на опыте. Да конечно я знаю, что в нормальных СУБД для построения ключа по строковому полю используется хэш значение этого самого поля записи, которое вычисляется перед тем, как записать ключ, НО, вот как раз-то на вычисление этого хэш значения и будет тратиться дополнительное время. Так что, вот так.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2007, 07:32:28 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2007, 13:55:10 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
osonспасибо Пожалуйста. А кстати, как там дела на поле брани? Просто интересно, что возобладало, разум или власть? С Уважением. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2007, 20:23:57 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Насчет, кто архитектуру разрабатывает - так он и разрабатывает, и базу, и архитектуру. Поэтому и менять не очень хочет, доводы странные на мой взгляд приводит. А закончилось просто - в базе осталось, как он хотел. Но теперь в сессии храниться все же обьект Person, который однако достается не по id, а по USERNAME. Хорошо, что в java код он не лез :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 11:42:19 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Да уж... Нет предела "совершенству" :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2007, 19:47:37 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
удивительно всё. Я реально смеялся: 1) "Но на вопрос, в чем преимущество такого подхода, я ответил только, что проще делать мэппинг в Hibernate". (при чём здесь Hibernate) 2) "Лучше использовать конечно-же суррогатный ключ в качестве РК. Кроме того, нормализацию баз данных - ещё никто не отменял." (а где же нормализация) 3) "Можно конечно и так, вот только здесь нужно задуматься о том, что к примеру тогда возрастает объём данных и снижается скорость запросов, т.к. число для сервера БД зачастую "весит" меньше чем символьные строки.И кстати ключи по числовым данным обычно работают быстрее чем по символьным, т.к. математика при этом работает быстрее." (абсолютное незнание того, как сервер обрабатывает и хранит различные типы данных) 4) " Т.к. это моё личное мнение, основанное на опыте. Да конечно я знаю, что в нормальных СУБД для построения ключа по строковому полю используется хэш значение этого самого поля записи, которое вычисляется перед тем, как записать ключ" (наверно, неправильно понял. Какой еще хэш?) Ребята, вы вообще это писали в добром здравии? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2007, 20:40:30 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Alex KuznetsovКроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня. Это всего лишь недостаток опыта работы с "системами промышленного уровня"... Таких фигней с денормализованными базами - моря-акияны. Причем некоторые из них - стоят в таких монструозных компаниях (типо оборот > 50 млрд.долл.) и стоят таких неимоверных денеХХХ, что диву даешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2007, 20:48:14 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Ыудивительно всё. Я реально смеялся: 1) "Но на вопрос, в чем преимущество такого подхода, я ответил только, что проще делать мэппинг в Hibernate". (при чём здесь Hibernate) при том что мэппинги для связей, когда в таблице натуральный кампаудный ключ, и на него ссылается другая таблица, довольно сложно делать и потом использовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2007, 13:52:30 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Зашедший Alex KuznetsovКроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня. Это всего лишь недостаток опыта работы с "системами промышленного уровня"... Таких фигней с денормализованными базами - моря-акияны. Причем некоторые из них - стоят в таких монструозных компаниях (типо оборот > 50 млрд.долл.) и стоят таких неимоверных денеХХХ, что диву даешься. Уважаемый господин "Зашедший", не Вам судить о моём опыте, из которого и работа с Oracle EBS, Oracle Collaboration Suite, SAP, RB SUN, RB Payroll, Expandable и разработка многих и мнигих прочих, как на MS SQL, так и на Oracle, Interbase, BTrieve и т.д. Так что не судите, да не судимы будете. Да, я согласен, что денормализованных данных в промышленных системах вагон и маленькая тележка, к примеру в том же SAP -е, тем не менее не стоит судить о МОИХ высказываниях, не вникнув в суть вопроса... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2007, 17:56:49 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Alex Kuznetsov Зашедший Alex KuznetsovКроме того, я не увидел такого изврата ни в одних нормальных боевых системам промышленного уровня. Это всего лишь недостаток опыта работы с "системами промышленного уровня"... Таких фигней с денормализованными базами - моря-акияны. Причем некоторые из них - стоят в таких монструозных компаниях (типо оборот > 50 млрд.долл.) и стоят таких неимоверных денеХХХ, что диву даешься. Уважаемый господин "Зашедший", не Вам судить о моём опыте, из которого и работа с Oracle EBS, Oracle Collaboration Suite, SAP, RB SUN, RB Payroll, Expandable и разработка многих и мнигих прочих, как на MS SQL, так и на Oracle, Interbase, BTrieve и т.д. Маэстро, покажите на примере из в ашего личного опыта как Alex Kuznetsovключи по числовым данным обычно работают быстрее чем по символьным, т.к. математика при этом работает быстрее . Публика ждет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2007, 18:54:31 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Timm Маэстро, покажите на примере из в ашего личного опыта как Публика ждет. Повторяю из предыдущего поста: ... PS. Сразу обращусь к тем, кто захочет меня попинать на почве ключей и производительности - отвечать не буду . ... Публика может ждать сколько угодно. Для примера, та же публика может поиграть с миллионами записей с ключами, построенными по символьным полям и по числовым (с использованием целых чисел). с замерами производительности и прочими танцами с бубнами. Ну, или на худой конец, поискать темы форумов по базам данных на интересующую тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2007, 20:20:04 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Alex Kuznetsov Timm Маэстро, покажите на примере из в ашего личного опыта как Публика ждет. Повторяю из предыдущего поста: ... PS. Сразу обращусь к тем, кто захочет меня попинать на почве ключей и производительности - отвечать не буду . ... Публика может ждать сколько угодно. Для примера, та же публика может поиграть с миллионами записей с ключами, построенными по символьным полям и по числовым (с использованием целых чисел). с замерами производительности и прочими танцами с бубнами. Ну, или на худой конец, поискать темы форумов по базам данных на интересующую тему. Ах, конечно. Чесать езыком все горазды. Как только конкретика - я супер-мега гуру, все идут лесом, ничо никому не должен. Фтопку таких м*даков. Простите за мой французский. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2007, 12:16:44 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Прошу прощения за оффтопик... Timm Ах, конечно. Чесать езыком все горазды. Как только конкретика - я супер-мега гуру, все идут лесом, ничо никому не должен. Фтопку таких м*даков. Простите за мой французский. Специально для Вас, неверующий и сомневающийся. Пример довольно прост. Производился на Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 2) (уж простите ради бога, "супер-мега гуру" - под рукой не оказалось Oracle-ового сервера). Характеристики машинки: Compaq nx7400: RAM: 1 Gb HDD: FUJITSU MHV2080BH PL IDE 70 Gb - разбит на два по 20 Gb и 50 Gb. Основной раздел - 20 Gb, на нем-же и тестовая база. CPU: Genuine Intel(R)CPU T2250 частота 1.73 GHz (Centrino Duo) OS: MS Windows XP Pro SP2 Думаю хватит об этом. А теперь собственно тестовый пример (предупреждаю сразу, что на тест уйдёт около 3-х минут): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. Результаты могут быть разными, НО, в основной массе ключ по целочисленному полю работает быстрее. Так что прежде чем м*удаком называть человека - нужно подумать. PS. За ваш французский не прощаю . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2007, 12:06:34 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
кузнецов +1 timm не комильфо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2007, 12:27:31 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
exppкузнецов +1 timm не комильфо Сорри, не понял... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2007, 12:50:36 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
exppкузнецов +1 timm не комильфо Всем, по -1, Зашедший не хотел никого обидеть. Просто сказал что существует море Legacy систем с дурацкой реализацией PK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2007, 13:18:51 |
|
||
|
Natural vs Synthetic primary keys
|
|||
|---|---|---|---|
|
#18+
Blazkowicz exppкузнецов +1 timm не комильфо Всем, по -1, Зашедший не хотел никого обидеть. Просто сказал что существует море Legacy систем с дурацкой реализацией PK. На "Зашедшего" никто и не в обиде, я ему ответил и думаю на этом вопрос с ним исчерпан. А вот за что по -1 - не понятно :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2007, 13:28:31 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=34412578&tid=2145735]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
42ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 272ms |
| total: | 426ms |

| 0 / 0 |
