Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

Anatoly Podgoretsky (2010-12-03 16:53:00) [1]
К тебе не было проблем, так что ты зря на свой повод брал.

sniknik (2010-12-03 16:46:00) [2]
> вот об этом миллионе
а... дошло. думал про "мой".

Anatoly Podgoretsky (2010-12-03 12:58:00) [3]
Да тут вообще нет предмета для обсуждения, шило с мылом, ежа с черепахой скрещивать.

12 (2010-12-03 12:30:00) [4]
автору
к Ega23 © (02.12.10 17:46) [12] +

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

12 (2010-12-03 12:25:00) [5]

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

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

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

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

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

sniknik (2010-12-03 12:00:00) [7]
"желаемый миллион" не имеет отношения к вопросу, он из опровержения на -
> Любой join - операция гораздо тяжелее, чем выборка из одной таблицы.
в случае автора оно конечно будет тяжелее, но "авторский случай" это не "любой" это скорее исключение.

Anatoly Podgoretsky (2010-12-03 11:52:00) [8]
> sniknik (03.12.2010 09:39:15) [15]

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

sniknik (2010-12-03 09:39:00) [9]
> Inovet © (02.12.10 21:55) [14]
нет, у него соединение в "ширину", один к одному, с.м. [6].

Inovet (2010-12-02 21:55:00) [10]
> [1] Ega23 © (02.12.10 16:38)
> Любой join

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

Anatoly Podgoretsky (2010-12-02 19:23:00) [11]

> svb (02.12.10 17:19) [6]

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

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

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

Ega23 (2010-12-02 17:46:00) [12]

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

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

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

Игорь Шевченко (2010-12-02 17:37:00) [13]
У оракла придумали секционирование таблиц. Наверное не с полной дури.

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

svb (2010-12-02 17:31:00) [14]
на самом деле задача обратная из множества таблиц собрать одну большую.

Ega23 (2010-12-02 17:29:00) [15]

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

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

Ega23 (2010-12-02 17:28:00) [16]

> 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=....даст нам нужные данные.
Теперь ещё триггеры на модификацию данных добавляем - и готово.

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

svb (2010-12-02 17:20:00) [17]
естественно при правильном индексировании и в первом и во втором случае

svb (2010-12-02 17:19:00) [18]

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

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

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

Медвежонок Пятачок (2010-12-02 17:09:00) [19]
Что будет лучше для производительности одна таблица с 1 000 000 записей или 10 связных таблиц по 100 000 записей?

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

sniknik (2010-12-02 17:08:00) [20]
> Любой join - операция гораздо тяжелее, чем выборка из одной таблицы.
неа, не любой.

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »