powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Одна большая или несколько малентких таблиц
25 сообщений из 46, страница 1 из 2
Одна большая или несколько малентких таблиц
    #35347801
Tarabtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Доброго дня.

Как организовать БД будет лучше: Одна большая или несколько маленьких таблиц?

Для примера 3 сущности:
1. Персонал
ID number,
FIO varchar
2. Партнеры
ID number,
FIO varchar
3. Клиенты
ID number,
FIO varchar


С точки зрения программирования с одной работать легче, а вот как со стороны БД?
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35347822
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вроде лучше по-другому...
1) Табличка Люди
2) Персонал (просто ссылки на людей)
3) Партнеры (тоже просто ссылки на людей)
4) Клиенты (тоже просто ссылки на людей)

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

Хотя как вы написали так тоже работать можно...
И вообще работать можно по всякому :)
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35347858
Tarabtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanВроде лучше по-другому...
1) Табличка Люди
2) Персонал (просто ссылки на людей)
3) Партнеры (тоже просто ссылки на людей)
4) Клиенты (тоже просто ссылки на людей)

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

Хотя как вы написали так тоже работать можно...
И вообще работать можно по всякому :)

Большое спасибо за ответ.
Понимаю, что работать можно по всякому :) - Главное чтоб работало
Интересно как какой подход влияет на производительности БД.
Ведь чем больше таблица, тем с ней тяжелей работать: больше операций чтений/записи с диска, индексы гораздо медленнее перестраиваются, да и надежность меньше (все яйца в одной карзине:) ).

ЗЫ Ннормализация - чаще во вред идет, а не во благо :) - Ккиллометровые запорсы потом получаются - по несколько часов их изучаешь, да и скорость выборки низкая-
Во всем нужна мера :)
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35347870
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TarabtsevИнтересно как какой подход влияет на производительности БД
Простите, но судя по Вашим постам, Вы не очень готовы к рассуждениям на тему производительности. В целом скажу так: всегда можно сделать хорошо и всегда можно сделать плохо, различия кроются на более тонком уровне, нежели "одна широкая или несколько узких". В плохо нормализованной БД "сделать плохо" намного легче. И я бы сказал, Вам стоит подумать в первую очередь о том, чтобы результат работал "почти без ошибок", а производительность - вопрос второй.

TarabtsevВедь чем больше таблица, тем с ней тяжелей работать: больше операций чтений/записи с диска, индексы гораздо медленнее перестраиваются, да и надежность меньше (все яйца в одной карзине:) ).

ЗЫ Ннормализация - чаще во вред идет, а не во благо :) - Ккиллометровые запорсы потом получаются - по несколько часов их изучаешь, да и скорость выборки низкая-
Надеюсь, Вы не сами это придумали.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35347936
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tarabtsev пишет:

> Ведь чем больше таблица, тем с ней тяжелей работать:

Это - лишь расхожее заблуждение.

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

Тоже в общем заблуждение.

>
> ЗЫ Ннормализация - чаще во вред идет, а не во благо :) - Ккиллометровые

Где вы там ненормальизацию увидали ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35347997
Tarabtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за ответы!

для softwarer :
Вопрос был: "Как организовать БД будет лучше: Одна большая или несколько маленьких таблиц?
" - про нормализацию и пр. вопроса не было.


Для MasterZiv :
> Это - лишь расхожее заблуждение.
> Тоже в общем заблуждение
Все же переспрошу в цифрах:
Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. Если мы объединим все таблицы в одну, как это повлияет на общую производительность системы суммарно по рабочим местам?
Либо наоборот: если одну большую разбить на 10 маленьких?
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348023
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Денормализацую нужно проводить по-уму.
Например, когда приходится через несколько таблиц продираться к какому-либо полю, чтобы сократить кол-во IO можно кое-что лишнее поместить в основной таблице, с таким расчетом чтобы в некоторых случаях можно было выбросить некоторые промежуточные таблицы из запроса. Но это нужно делать очень осторожно.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348283
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор
Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. Если мы объединим все таблицы в одну, как это повлияет на общую производительность системы суммарно по рабочим местам?
Либо наоборот: если одну большую разбить на 10 маленьких?

Эт о партишинге что-ли? (table partition) А это то с какого тута?...
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348372
Tarabtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman
Эт о партишинге что-ли? (table partition) А это то с какого тута?...

Никакого партишинга. Вопрос: "как лучше: Одна большая или несколько маленьких таблиц"?
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348563
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Tarabtsev пишет:

> > Это - лишь расхожее заблуждение.
> > Тоже в общем заблуждение
> Все же переспрошу в цифрах:
> Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа
> 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1
> операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест
> работают со веми операциями. Если мы объединим все таблицы в одну, как
> это повлияет на общую производительность системы суммарно по рабочим
> местам?

Практически никак. Конечно, зависит от сути этих операций и от
кривости рук программиста, но если криминал не брать в расчет - никак.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348619
Tarabtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Практически никак. Конечно, зависит от сути этих операций и от
кривости рук программиста, но если криминал не брать в расчет - никак.

Posted via ActualForum NNTP Server 1.4

Спасибо
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348739
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TarabtsevВсе же переспрошу в цифрах:
Допустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. Если мы объединим все таблицы в одну, как это повлияет на общую производительность системы суммарно по рабочим местам?
Либо наоборот: если одну большую разбить на 10 маленьких?В цифрах, понятное дело, выигрыш будет за 10 маленькими таблицами, но будет ли он такой большой как кажется и будет ли он ВО ВСЕМ.

А именно:
1) Что мы будем делать, если одна операция должна будет попадать в "тип 1" и "тип 2"?
В вашем случае с людьми. Что делать, если Поставщик и Клиент одно лицо?
Для 10 таблиц придется сделать 45 таблиц связей много ко-многому, чтобы их повязать между собой. Или... сделть одну большую объединяющую таблицу.

2) Как будет выглядеть запрос, если нам понадобится операции любого типа?
кроме как 10 union-ов вариантов особо нет. "Красивым" это врядли можно назвать.
Если потом к этому результату надо приджоинить еще пару таблиц - шансов на построение оптимального запроса становится еще меньше.
Кроме этого, если результат 10 юнионов попытаться отсортировать по дате создания (например), то это будет гораздо дольше, чем сортировка по аналогичному проиндексированному полю в отдельной таблице.

3) Партиционирование часто спасает от создания архивных/дублирующих и пр. таблиц, которые создают для уменьшения выборки.
Лучше использовать партиционирование, чем доморощенное разбиение и сборку на уровне таблиц.

4) Большой индекс не обязательно означает медленный поиск.

Так что ваши утверждения скорее заблуждения и выигрыша будет меньше, чем проигрыша.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348752
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyВ цифрах, понятное дело, выигрыш будет за 10 маленькими таблицами
Я бы очень похмыкал на тему "понятно", поскольку существенно зависит от выполняемых запросов. "Понятный" выигрыш будет только для запросов вида full table scan of small table.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348780
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer BelyВ цифрах, понятное дело, выигрыш будет за 10 маленькими таблицами
Я бы очень похмыкал на тему "понятно", поскольку существенно зависит от выполняемых запросов. "Понятный" выигрыш будет только для запросов вида full table scan of small table.Я имел ввиду случай, описанный автором.

Tarabtsev50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями.

Собственно, такое разбиение на части есть ни что иное, как доморощенное партиционирование.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348796
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bely пишет:

> 4) Большой индекс не обязательно означает медленный поиск.

Он вообще не означает медленный поиск.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348807
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
Bely пишет:
> 4) Большой индекс не обязательно означает медленный поиск.
Он вообще не означает медленный поиск.Бывают случа, когда FULL SCAN эффективнее, чем поиск по индексу.
Это уже классика...
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35348911
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyЯ имел ввиду случай, описанный автором
Я не вижу в описании автора ничего, что дало бы основания говорить "понятно, быстрее".

BelyСобственно, такое разбиение на части есть ни что иное, как доморощенное партиционирование.
Ну не совсем. С тем же успехом это могут быть "разные, но пока похожие" таблицы документов с разными правами доступа (на что пригодится разбиение на отдельные таблицы) итп.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35349060
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer BelyЯ имел ввиду случай, описанный авторомЯ не вижу в описании автора ничего, что дало бы основания говорить "понятно, быстрее".
автор50 рабочих мест работает только с 1 операцией Доступ к отдельной таблице будет быстрее, чем к тем же данным в большой таблице (без партиционирования).
Не сильно быстрее при правильном проектировании, но быстрее.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35349093
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
SQL> create table small as select rownum id, lpad ('*',  100 , '*') data from dual connect by level <=  1000 ;

Table created

SQL> create table big as select rownum id, lpad ('*',  100 , '*') data from dual connect by level <=  1000000 ;

Table created

SQL> alter table small add primary key (id);

Table altered

SQL> alter table big add primary key (id);

Table altered

SQL> set timing on;

SQL> declare d small.data%type;
   2   begin
   3     for i in  1 .. 1000  loop
   4       select data into d from small where id = i;
   5     end loop;
   6   end;
   7   /

PL/SQL procedure successfully completed

Executed in  0 , 079  seconds

SQL> declare d big.data%type;
   2   begin
   3     for i in  1 .. 1000  loop
   4       select data into d from big where id =  1000  * i;
   5     end loop;
   6   end;
   7   /

PL/SQL procedure successfully completed

Executed in  14 , 563  seconds

SQL> declare d big.data%type;
   2   begin
   3     for i in  1 .. 1000  loop
   4       select data into d from big where id =  1000  * i;
   5     end loop;
   6   end;
   7   /

PL/SQL procedure successfully completed

Executed in  0 , 078  seconds

SQL> 
SQL> declare d small.data%type;
   2   begin
   3     for i in  1 .. 1000  loop
   4       select data into d from small where id = i;
   5     end loop;
   6   end;
   7   /

PL/SQL procedure successfully completed

Executed in  0 , 047  seconds

SQL> 
SQL> declare d big.data%type;
   2   begin
   3     for i in  1 .. 1000  loop
   4       select data into d from big where id =  1000  * i;
   5     end loop;
   6   end;
   7   /

PL/SQL procedure successfully completed

Executed in  0 , 047  seconds

SQL> 
SQL> declare d small.data%type;
   2   begin
   3     for i in  1 .. 1000  loop
   4       select data into d from small where id = i;
   5     end loop;
   6   end;
   7   /

PL/SQL procedure successfully completed

Executed in  0 , 047  seconds

SQL> 
SQL> declare d big.data%type;
   2   begin
   3     for i in  1 .. 1000  loop
   4       select data into d from big where id =  1000  * i;
   5     end loop;
   6   end;
   7   /

PL/SQL procedure successfully completed

Executed in  0 , 046  seconds
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35351506
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerГде быстрее? Ткните, пожалуйста, пальцем.Эксперимент пока поставить не могу, но общий смысл такой.

Много маленьких таблиц:
Люди, которые работают с каждой операцией делают запросы вида:
Код: plaintext
1.
2.
SELECT *
FROM small
WHERE ... условия...

Для большой таблицы необходимо будет создать дополнительное поле TYPE_ID в которое будет записан тип операции.
По этому полю надо будет построить индекс. Оператор, который будет работать с одной операцией будет делать запросы вида:
Код: plaintext
1.
2.
3.
SELECT *
FROM big
WHERE TYPE_ID =  1 
  and ... условия...
т.е. сперва чтение блоков индекса, а потом уже блоков данных.
Это при условии, что для этой таблицы не будет партиционирования по полю TYPE_ID
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35351623
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
BelyЛюди, которые работают с каждой операцией делают запросы вида:
... где условие в половине случаев - выбор записи по первичному ключу.

BelyДля большой таблицы необходимо будет создать дополнительное поле TYPE_ID в которое будет записан тип операции. По этому полю надо будет построить индекс.
Это вряд ли. Включить поле в некоторые существующие индексы - наверное, а строить отдельный... трудно придумать, когда он пригодится.

BelyОператор, который будет работать с одной операцией будет делать запросы вида:
Код: plaintext
1.
2.
3.
SELECT *
FROM big
WHERE TYPE_ID =  1 
  and ... условия...
т.е. сперва чтение блоков индекса, а потом уже блоков данных.
Я крайне сомневаюсь в том, что запросы будут использовать индекс по type_id. Для OLTP систем характерны в целом следующие типы запросов:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
  1  

select /*+ first_rows */ field1, field2, ....
from table1 [, table2 ...]
where <условия>
order by date_field desc 

  2 

select * from table where id = :id

  3 

select * from table where parent_id = :id order by something

  4 

/* нечто навороченное сложное расчетное */

Вероятность того, что поле сортировки окажется неиндексированным, и в условиях тоже не попадется критерия получше, нежели type_id - имхо весьма мала. При прочих операциях это условие вообще не нужно.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35351767
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerВключить поле в некоторые существующие индексы - наверноеИндекс по двум полям больше по размеру, чем индекс по одному полю.
Соответственно будет считано большее кол-во блоков индекса для выборки по одному и тому же условию.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35355425
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bely пишет:

> Доступ к отдельной таблице будет быстрее, чем к тем же данным в большой
> таблице (без партиционирования).
> Не сильно быстрее при правильном проектировании, но быстрее.

В каком случае ?
При доступе по индексу - медленнее к N таблицам, чем к одной
(имею в виду range scan). При скане всех таблиц - такая же.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35356065
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivВ каком случае ?
При доступе по индексу - медленнее к N таблицам, чем к одной
(имею в виду range scan). При скане всех таблиц - такая же.Обоснуйте, почему при доступе к данным операции одного типа доступ будет медленне для нескольких таблиц, чем для всех данных слитых в одну таблицу?

Примеры запросов - в предыдущих постах.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35356173
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
...
Рейтинг: 0 / 0
25 сообщений из 46, страница 1 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Одна большая или несколько малентких таблиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]