|
|
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Доброго дня. Как организовать БД будет лучше: Одна большая или несколько маленьких таблиц? Для примера 3 сущности: 1. Персонал ID number, FIO varchar 2. Партнеры ID number, FIO varchar 3. Клиенты ID number, FIO varchar С точки зрения программирования с одной работать легче, а вот как со стороны БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2008, 18:14 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Вроде лучше по-другому... 1) Табличка Люди 2) Персонал (просто ссылки на людей) 3) Партнеры (тоже просто ссылки на людей) 4) Клиенты (тоже просто ссылки на людей) Ну это конечно в том случае если вы ток с людьми работаете. Если организации, то сложнее. Почитайте про нормализацию... Хотя как вы написали так тоже работать можно... И вообще работать можно по всякому :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2008, 18:38 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
gardenmanВроде лучше по-другому... 1) Табличка Люди 2) Персонал (просто ссылки на людей) 3) Партнеры (тоже просто ссылки на людей) 4) Клиенты (тоже просто ссылки на людей) Ну это конечно в том случае если вы ток с людьми работаете. Если организации, то сложнее. Почитайте про нормализацию... Хотя как вы написали так тоже работать можно... И вообще работать можно по всякому :) Большое спасибо за ответ. Понимаю, что работать можно по всякому :) - Главное чтоб работало Интересно как какой подход влияет на производительности БД. Ведь чем больше таблица, тем с ней тяжелей работать: больше операций чтений/записи с диска, индексы гораздо медленнее перестраиваются, да и надежность меньше (все яйца в одной карзине:) ). ЗЫ Ннормализация - чаще во вред идет, а не во благо :) - Ккиллометровые запорсы потом получаются - по несколько часов их изучаешь, да и скорость выборки низкая- Во всем нужна мера :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2008, 19:16 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
TarabtsevИнтересно как какой подход влияет на производительности БД Простите, но судя по Вашим постам, Вы не очень готовы к рассуждениям на тему производительности. В целом скажу так: всегда можно сделать хорошо и всегда можно сделать плохо, различия кроются на более тонком уровне, нежели "одна широкая или несколько узких". В плохо нормализованной БД "сделать плохо" намного легче. И я бы сказал, Вам стоит подумать в первую очередь о том, чтобы результат работал "почти без ошибок", а производительность - вопрос второй. TarabtsevВедь чем больше таблица, тем с ней тяжелей работать: больше операций чтений/записи с диска, индексы гораздо медленнее перестраиваются, да и надежность меньше (все яйца в одной карзине:) ). ЗЫ Ннормализация - чаще во вред идет, а не во благо :) - Ккиллометровые запорсы потом получаются - по несколько часов их изучаешь, да и скорость выборки низкая- Надеюсь, Вы не сами это придумали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2008, 19:29 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Tarabtsev пишет: > Ведь чем больше таблица, тем с ней тяжелей работать: Это - лишь расхожее заблуждение. больше операций > чтений/записи с диска, индексы гораздо медленнее перестраиваются, да и > надежность меньше (все яйца в одной карзине:) ). Тоже в общем заблуждение. > > ЗЫ Ннормализация - чаще во вред идет, а не во благо :) - Ккиллометровые Где вы там ненормальизацию увидали ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2008, 20:58 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответы! для softwarer : Вопрос был: "Как организовать БД будет лучше: Одна большая или несколько маленьких таблиц? " - про нормализацию и пр. вопроса не было. Для MasterZiv : > Это - лишь расхожее заблуждение. > Тоже в общем заблуждение Все же переспрошу в цифрах: Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. Если мы объединим все таблицы в одну, как это повлияет на общую производительность системы суммарно по рабочим местам? Либо наоборот: если одну большую разбить на 10 маленьких? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2008, 22:34 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Денормализацую нужно проводить по-уму. Например, когда приходится через несколько таблиц продираться к какому-либо полю, чтобы сократить кол-во IO можно кое-что лишнее поместить в основной таблице, с таким расчетом чтобы в некоторых случаях можно было выбросить некоторые промежуточные таблицы из запроса. Но это нужно делать очень осторожно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2008, 23:16 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
автор Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. Если мы объединим все таблицы в одну, как это повлияет на общую производительность системы суммарно по рабочим местам? Либо наоборот: если одну большую разбить на 10 маленьких? Эт о партишинге что-ли? (table partition) А это то с какого тута?... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 10:09 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
gardenman Эт о партишинге что-ли? (table partition) А это то с какого тута?... Никакого партишинга. Вопрос: "как лучше: Одна большая или несколько маленьких таблиц"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 10:42 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Tarabtsev пишет: > > Это - лишь расхожее заблуждение. > > Тоже в общем заблуждение > Все же переспрошу в цифрах: > Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа > 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 > операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест > работают со веми операциями. Если мы объединим все таблицы в одну, как > это повлияет на общую производительность системы суммарно по рабочим > местам? Практически никак. Конечно, зависит от сути этих операций и от кривости рук программиста, но если криминал не брать в расчет - никак. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 11:45 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
MasterZiv Практически никак. Конечно, зависит от сути этих операций и от кривости рук программиста, но если криминал не брать в расчет - никак. Posted via ActualForum NNTP Server 1.4 Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 12:07 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
TarabtsevВсе же переспрошу в цифрах: Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. Если мы объединим все таблицы в одну, как это повлияет на общую производительность системы суммарно по рабочим местам? Либо наоборот: если одну большую разбить на 10 маленьких?В цифрах, понятное дело, выигрыш будет за 10 маленькими таблицами, но будет ли он такой большой как кажется и будет ли он ВО ВСЕМ. А именно: 1) Что мы будем делать, если одна операция должна будет попадать в "тип 1" и "тип 2"? В вашем случае с людьми. Что делать, если Поставщик и Клиент одно лицо? Для 10 таблиц придется сделать 45 таблиц связей много ко-многому, чтобы их повязать между собой. Или... сделть одну большую объединяющую таблицу. 2) Как будет выглядеть запрос, если нам понадобится операции любого типа? кроме как 10 union-ов вариантов особо нет. "Красивым" это врядли можно назвать. Если потом к этому результату надо приджоинить еще пару таблиц - шансов на построение оптимального запроса становится еще меньше. Кроме этого, если результат 10 юнионов попытаться отсортировать по дате создания (например), то это будет гораздо дольше, чем сортировка по аналогичному проиндексированному полю в отдельной таблице. 3) Партиционирование часто спасает от создания архивных/дублирующих и пр. таблиц, которые создают для уменьшения выборки. Лучше использовать партиционирование, чем доморощенное разбиение и сборку на уровне таблиц. 4) Большой индекс не обязательно означает медленный поиск. Так что ваши утверждения скорее заблуждения и выигрыша будет меньше, чем проигрыша. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 12:45 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
BelyВ цифрах, понятное дело, выигрыш будет за 10 маленькими таблицами Я бы очень похмыкал на тему "понятно", поскольку существенно зависит от выполняемых запросов. "Понятный" выигрыш будет только для запросов вида full table scan of small table. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 12:49 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
softwarer BelyВ цифрах, понятное дело, выигрыш будет за 10 маленькими таблицами Я бы очень похмыкал на тему "понятно", поскольку существенно зависит от выполняемых запросов. "Понятный" выигрыш будет только для запросов вида full table scan of small table.Я имел ввиду случай, описанный автором. Tarabtsev50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. Собственно, такое разбиение на части есть ни что иное, как доморощенное партиционирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 12:59 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Bely пишет: > 4) Большой индекс не обязательно означает медленный поиск. Он вообще не означает медленный поиск. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 13:04 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
MasterZiv Bely пишет: > 4) Большой индекс не обязательно означает медленный поиск. Он вообще не означает медленный поиск.Бывают случа, когда FULL SCAN эффективнее, чем поиск по индексу. Это уже классика... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 13:06 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
BelyЯ имел ввиду случай, описанный автором Я не вижу в описании автора ничего, что дало бы основания говорить "понятно, быстрее". BelyСобственно, такое разбиение на части есть ни что иное, как доморощенное партиционирование. Ну не совсем. С тем же успехом это могут быть "разные, но пока похожие" таблицы документов с разными правами доступа (на что пригодится разбиение на отдельные таблицы) итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 13:39 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
softwarer BelyЯ имел ввиду случай, описанный авторомЯ не вижу в описании автора ничего, что дало бы основания говорить "понятно, быстрее". автор50 рабочих мест работает только с 1 операцией Доступ к отдельной таблице будет быстрее, чем к тем же данным в большой таблице (без партиционирования). Не сильно быстрее при правильном проектировании, но быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 14:21 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Bely50 рабочих мест работает только с 1 операцией Угу. А другие 50 рабочих мест - с разными. И значит время от времени будут выполнять union-ы или подобные по смыслу операции. BelyДоступ к отдельной таблице будет быстрее, чем к тем же данным в большой таблице (без партиционирования) C какой это вдруг стати? BelyНе сильно быстрее при правильном проектировании, но быстрее. Где быстрее? Ткните, пожалуйста, пальцем. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2008, 14:35 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
softwarerГде быстрее? Ткните, пожалуйста, пальцем.Эксперимент пока поставить не могу, но общий смысл такой. Много маленьких таблиц: Люди, которые работают с каждой операцией делают запросы вида: Код: plaintext 1. 2. Для большой таблицы необходимо будет создать дополнительное поле TYPE_ID в которое будет записан тип операции. По этому полю надо будет построить индекс. Оператор, который будет работать с одной операцией будет делать запросы вида: Код: plaintext 1. 2. 3. Это при условии, что для этой таблицы не будет партиционирования по полю TYPE_ID ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2008, 15:05 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
BelyЛюди, которые работают с каждой операцией делают запросы вида: ... где условие в половине случаев - выбор записи по первичному ключу. BelyДля большой таблицы необходимо будет создать дополнительное поле TYPE_ID в которое будет записан тип операции. По этому полю надо будет построить индекс. Это вряд ли. Включить поле в некоторые существующие индексы - наверное, а строить отдельный... трудно придумать, когда он пригодится. BelyОператор, который будет работать с одной операцией будет делать запросы вида: Код: plaintext 1. 2. 3. Я крайне сомневаюсь в том, что запросы будут использовать индекс по type_id. Для OLTP систем характерны в целом следующие типы запросов: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Вероятность того, что поле сортировки окажется неиндексированным, и в условиях тоже не попадется критерия получше, нежели type_id - имхо весьма мала. При прочих операциях это условие вообще не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2008, 15:41 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
softwarerВключить поле в некоторые существующие индексы - наверноеИндекс по двум полям больше по размеру, чем индекс по одному полю. Соответственно будет считано большее кол-во блоков индекса для выборки по одному и тому же условию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2008, 16:30 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Bely пишет: > Доступ к отдельной таблице будет быстрее, чем к тем же данным в большой > таблице (без партиционирования). > Не сильно быстрее при правильном проектировании, но быстрее. В каком случае ? При доступе по индексу - медленнее к N таблицам, чем к одной (имею в виду range scan). При скане всех таблиц - такая же. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2008, 01:52 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
MasterZivВ каком случае ? При доступе по индексу - медленнее к N таблицам, чем к одной (имею в виду range scan). При скане всех таблиц - такая же.Обоснуйте, почему при доступе к данным операции одного типа доступ будет медленне для нескольких таблиц, чем для всех данных слитых в одну таблицу? Примеры запросов - в предыдущих постах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2008, 12:00 |
|
||
|
Одна большая или несколько малентких таблиц
|
|||
|---|---|---|---|
|
#18+
Bely пишет: > Обоснуйте, почему при доступе к данным операции одного типа доступ будет > медленне для нескольких таблиц, чем для всех данных слитых в одну таблицу? range scan по индексу состоит из двух этапов 1) позиционирование по индексу на начало диапазона - Oi 2) сканирование таблицы в направлении возрастания диапазона до достижения конца диапазона. Os Если мы имеем одну таблицу, мы имеем O = Oi + Os Если, например, три, то O = Oi1 + Os1 + Oi2 + Os2 + Oi3 + Os3 Os1 + Os2 + Os3 = Os (мы разбиваем таблицу, но кол-во строк не меняется). Oi = log( N ) Oi1 = log (N/3) = log(N) - log (3) Следовательно, Oi1 ~= Oi2 ~= Oi3 ~= Oi Итого, получаем для трех таблиц O = 3 * Oi + Os, что больше Oi + Os Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2008, 12:24 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=35348023&tid=1543832]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
172ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 529ms |

| 0 / 0 |
