Одна таблица или много маленьких

← →
svb (2010-12-02 16:16) [0]

Здравствуйте.
Есть вопрос по организации БД(MSSQL 2005).
Что будет лучше для производительности одна таблица с 1 000 000 записей или 10 связных таблиц по 100 000 записей? понятно что вопрос размытый. Хотелось для начала узнать как будет вести себя одна таблица если к ней одновременно обратится 10 к запросов на insert/update/delete и 30 запросов на select эти запросы распаралелятся или будут стоять все в очереди? и как допустим будет вести себя поиск по like в случае с одной страницей и в случае с 10 страниц?
Можно тынцкнуть меня на какую нибудь статейку)). Гугл что то от меня скрывает, там ниче подходящего не нашел, мож не там исакл.

← →
Ega23 © (2010-12-02 16:38) [1]

> Можно тынцкнуть меня на какую нибудь статейку

Лучшая статейка по MSSQL - это BOL.
Читай про индексирование, Transaction isolation level, ну и т.д.
В целом, MSSQL больше блокировщик, нежели версионник, поэтому надо грамотно индексы расставлять, чтобы только определённую страницу блокировала.

А в целом, разбивать или нет на 10 таблиц. Любой join - операция гораздо тяжелее, чем выборка из одной таблицы. Если у тебя есть уверенность, что данные лежат в определённой таблице - можно и разбить.

← →
Anatoly Podgoretsky © (2010-12-02 17:00) [2]

> svb (02.12.2010 16:16:00) [0]

Связаных это как?

← →
Anatoly Podgoretsky © (2010-12-02 17:01) [3]

> svb (02.12.2010 16:16:00) [0]

Миллион записей для MSSQL это ничтожное количество.

← →
sniknik © (2010-12-02 17:08) [4]

> Любой join - операция гораздо тяжелее, чем выборка из одной таблицы.
неа, не любой.

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

← →
Медвежонок Пятачок © (2010-12-02 17:09) [5]

Что будет лучше для производительности одна таблица с 1 000 000 записей или 10 связных таблиц по 100 000 записей?

Для производительности будет лучше, когда число людей юзающих и программирующих сервер и задающихся такими вопросами будет меньше.

← →
svb (2010-12-02 17:19) [6]

> Для производительности будет лучше, когда число людей юзающих
> и программирующих сервер и задающихся такими вопросами будет
> меньше.

если нечего написать по сути, зачем вообще писать?

>[4]
это понятно интересует немного другое, что будет быстрее выполняться на больших объемах?
select * from tb where idtype = 1
предположим вернулось две записи
select * from tb inner join tb1 ON tb.idtype=tb1.idtype where tb.idtype = 1
вернулись теже данные что и в первом случае (только уже получиться одной строкой)

← →
svb (2010-12-02 17:20) [7]

естественно при правильном индексировании и в первом и во втором случае

← →
Ega23 © (2010-12-02 17:28) [8]

> sniknik © (02.12.10 17:08) [4]
> неа, не любой.
>
> например представь основную таблицу на миллион записей,
> и присоединяемую маленькую с названиями/типами на всего
> 10 записей, присоединяются полю интеджер.

Если я правильно понял автора, то он хочет основную таблицу разбить на 10. Каждая из которых в твоём примере будет соединена со вспомогательной.
Т.е. не в нормализации дело.

Такой подход достаточно активно в Postgres используется. Но изящно это можно сделать, только обладая возможностями наследования таблиц, как в Postgres.

Самый простой пример - есть продажи по месяцам.
1. Заводим таблицу Sales
2. Заводим 12 таблиц Sales_1 inherits Sales, Sales_2 inherits Sales, .... , Sales_12 inherits Sales.
3. Пишем триггер на Select для Sales, где вытягиваем номер месяца из параметра. Обращаемся к нужной таблице.
4. Вуаля. Теперь любой запрос Select * from Sales where Month=.... даст нам нужные данные.
Теперь ещё триггеры на модификацию данных добавляем - и готово.

Но это только если я правильно понял то, чего хочет автор.

← →
Ega23 © (2010-12-02 17:29) [9]

> что будет быстрее выполняться на больших объемах?

План запроса придуман для трусов и ботаников?

← →
svb (2010-12-02 17:31) [10]

на самом деле задача обратная из множества таблиц собрать одну большую.

← →
Игорь Шевченко © (2010-12-02 17:37) [11]

У оракла придумали секционирование таблиц. Наверное не с полной дури.

Но в случае 100000 и 1000000 записей это конечно несерьезно

← →
Ega23 © (2010-12-02 17:46) [12]

> на самом деле задача обратная из множества таблиц собрать
> одну большую.

1. Сделать и так и так. Поиграться с индексами. Сравнить результаты.
2. Читать внимательно BOL в части индексирования
3. Читать статьи на sql.ru в соответствующем разделе.
4. Также следует обратить внимание на специфику High-load проектов. Там зачастую идут на осознанную денормализацию, порой даже ключей вторичных нет.
5. Ещё следует обратить внимание на характер доступа к данным. Чего больше, чтения или записи? Как часто меняются данные? Насколько помогает DBREINDEX?

ИМХО, общего решения нет, надо играться.

← →
Anatoly Podgoretsky © (2010-12-02 19:23) [13]

> svb (02.12.10 17:19) [6]

Два абсолютно разных по идеологии, наначению и с разным количеством строк в результате.

Сравнивать их, в свете разделения, это просто дурдом
Соединение расширяет результат в ширину, а не в длину.

А объединять в длину, просто нет смысла по сравнению с единой таблицей, это огромный минус в производительности, большая сложность составляения запросов и прочие про

← →
Inovet © (2010-12-02 21:55) [14]

> [1] Ega23 © (02.12.10 16:38)
> Любой join

А я понял так: автор хочет одну таблицу разделить на несколько с такой же структурой, что есть глупость.

← →
sniknik © (2010-12-03 09:39) [15]

> Inovet © (02.12.10 21:55) [14]
нет, у него соединение в "ширину", один к одному, с.м. [6].

← →
Anatoly Podgoretsky © (2010-12-03 11:52) [16]

> sniknik (03.12.2010 09:39:15) [15]

Откуда тогда вознет желаемый миллион из 100 000

"желаемый миллион" не имеет отношения к вопросу, он из опровержения на -
> Любой join - операция гораздо тяжелее, чем выборка из одной таблицы.
в случае автора оно конечно будет тяжелее, но "авторский случай" это не "любой" это скорее исключение.

> [17] sniknik © (03.12.10 12:00)
> "желаемый миллион" не имеет отношения к вопросу

вот об этом миллионе

> [0] svb (02.12.10 16:16)
> одна таблица с 1 000 000 записей или 10 связных таблиц по 100 000 записей

> У оракла придумали секционирование таблиц. Наверное не с
> полной дури.

тащусь от этого!!!
когда придумывал подобный механизм для mssql на уровне логики - все проклял :)

автору
к Ega23 © (02.12.10 17:46) [12] +

как делал когда то
0. накопить реальные запросы (трассировщиком)
1. сделать копии БД, поднять их несколько
2. проиндексировать по-разному каждую. Упор - на кластерный
3. провернуть запросы на каждой, сравнить
+ Читать статьи на sql.ru (еще раз)

Да тут вообще нет предмета для обсуждения, шило с мылом, ежа с черепахой скрещивать.

> вот об этом миллионе
а... дошло. думал про "мой".

К тебе не было проблем, так что ты зря на свой повод брал.

Одна таблица или много маленьких Найти похожие ветки