powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Одна большая или несколько малентких таблиц
46 сообщений из 46, показаны все 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
Одна большая или несколько малентких таблиц
    #35356963
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivrange scan по индексу состоит из двух этапов
1) позиционирование по индексу на начало диапазона - Oi
2) сканирование таблицы в направлении возрастания диапазона до достижения конца
диапазона.
Ээ.... неужели в мире есть СУБД, в которой все действительно так? Или Вы говорите о range scan по индекс-организованной таблице?
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35357140
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivЕсли мы имеем одну таблицу,
мы имеем
O = Oi + Os
Если, например, три, то
O = Oi1 + Os1 + Oi2 + Os2 + Oi3 + Os3при всем при этом было бы круто, чтобы Вы рассматривали не какую-то свою задачу, а ту которую обсуждали здесь все.
А именно:
авторДопустим есть 10 таблиц(учет операций: оп.типа 1, оп.типа 2,..., оп.типа 10) с миллионом записей в каждой. 50 рабочих мест работает только с 1 операцией(у каждого места свой тип), 30 мест по 5 операций и 20 мест работают со веми операциями. При этом я говорил про случай:
автор50 рабочих мест работает только с 1 операциейСоответственно, где здесь будет RangeScan по трем таблицам?
Для 1 операции все запросы из одной таблицы идут при любом варианте хранения.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35357755
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bely пишет:

> при всем при этом было бы круто, чтобы Вы рассматривали не какую-то свою
> задачу, а ту которую обсуждали здесь все.

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

> Ээ.... неужели в мире есть СУБД, в которой все действительно так? Или Вы
> говорите о range scan по индекс-организованной таблице?


Что значит индекс - организованная таблица ?


Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35357780
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivЧто значит индекс - организованная таблица ?
Таблица, в которой записи физически размещены в порядке сортировки (то есть, например, изменение ключевого поля приводит к физическому перемещению записи). Index organized table в Oracle, table with clustered index в MSSQL итп.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35358072
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer пишет:

> Таблица, в которой записи физически размещены в порядке сортировки (то
> есть, например, изменение ключевого поля приводит к физическому
> перемещению записи). Index organized table в Oracle, table with
> clustered index в MSSQL итп.

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

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

> Считывание диапазона индекса,

ВСЕГО диапазона ? И куда же считывать будем ?

сортировка адресов и собственно
> определение "начала и конца диапазона в таблице".

Зачем ?

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

Операции - бизнес операции, информация о которых сохраняется в БД.
Какие именно операци, какие данные сохраняются - не важно.
Это модель.

MasterZivНо в общем случае смысла разбивать горизонтально таблицу на куски нет,
если это конечно не VLDB.Обосновать можете почему нет?
Некторые ПРЕДНАМЕРЕННО и ОБДУМАННО так делают.

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

А у вас есть "направление возрастания блоков БД" ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35360645
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv
softwarer пишет:
> тому, куда показывает очередной адрес, либо же прочитать диапазон
> индекса, составить список адресов блоков и их уже читать "по направлению
> возрастания".

А у вас есть "направление возрастания блоков БД" ?У дисковых накопителей (которые являются наиболее распространенными накопителями для БД) есть особенность, что последовательное чтение заметно быстрее, чем хаотическое позиционирование магнитной головки.

Так что это тоже имеет смысл.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35360694
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivА у вас есть "направление возрастания блоков БД" ?
Боюсь, в первую очередь я не совсем понял Ваше удивление. О сканировании таблицы в направлении возрастания сказали Вы, я использую слова ровно в таком же смысле (надеюсь, мы согласны, что таблица состоит из блоков?)

Во-вторых таки вообще говоря да. Дисковый накопитель выполняет команду "прочитать дорожку" значительно быстрее, нежели читает ту же дорожку посекторно, а головку на соседнюю дорожку позиционирует значительно быстрее, чем при путешествии через пол-диска. Поэтому если мы не будем стараться очень извратно разбросать фрагменты файлов БД по диску, чтение их по порядку даст выигрыш по сравнению со случайным.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35360828
telcomp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
загляните вот сюда плиз http://www.sql.ru/forum/actualthread.aspx?tid=562907
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35361551
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Bely пишет:

> У дисковых накопителей (которые являются наиболее распространенными
> накопителями для БД) есть особенность, что последовательное чтение
> заметно быстрее, чем хаотическое позиционирование магнитной головки.

Современная СУБД чаще всего ничего про диск не знает.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35361580
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivСовременная СУБД чаще всего ничего про диск не знает.
Что не мешает ей от него зависеть. Признаться, давно не обновлял сведения по архитектуре популярных файловых систем, но те, которые помню, оптимизированы именно под последовательное чтение файла.
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35361583
Через RAW
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MasterZivСовременная СУБД чаще всего ничего про диск не знает.Как же тогда MS SQL сервер работает с неразмеченными областями и дисками (raw) ?
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35363178
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer MasterZivА у вас есть "направление возрастания блоков БД" ?
Боюсь, в первую очередь я не совсем понял Ваше удивление. О сканировании таблицы в направлении возрастания сказали Вы, я использую слова ровно в таком же смысле (надеюсь, мы согласны, что таблица состоит из блоков?)

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

Не очень понимаю, как это согласуется с многопользовательским и многозадачным режимами работы серверов (железных). Пока мы будем ждать результаты своего запроса, к серверу еще сто человек может обратиться, причем совсем не обязательно - именно через СУБД. И куда денется наше последовательное чтение, если в это же время с диска еще сто задач прочитают то, что им надо?
Или сервер БД делает каждый свой запрос в монопольном режиме?
...
Рейтинг: 0 / 0
Одна большая или несколько малентких таблиц
    #35363983
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Николай1Не очень понимаю, как это согласуется с многопользовательским и многозадачным режимами работы серверов (железных). Пока мы будем ждать результаты своего запроса, к серверу еще сто человек может обратиться, причем совсем не обязательно - именно через СУБД. И куда денется наше последовательное чтение, если в это же время с диска еще сто задач прочитают то, что им надо?
Или сервер БД делает каждый свой запрос в монопольном режиме?Начнем с того, что любой запрос к одному диску (одному процессору, одной сетевой карте и пр.) выполняется в моно пользовательском режиме, пока не наступит переключение между задачами.
Просто потому, что большинство устройств не умеет работать в параллельном режиме.

Что касается жлступа к диску и СУБД.
Именно для того, чтобы исключить влияние прочей нагрузки на подсистему ввода-выода, рекомендуют разносить по разным каналам и дискам данные БД и прочие данные.
...
Рейтинг: 0 / 0
46 сообщений из 46, показаны все 2 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Одна большая или несколько малентких таблиц
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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