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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


предположим вернулось две записи


вернулись теже данные что и в первом случае (только уже получиться одной строкой)

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

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

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

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


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

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

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

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

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


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

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

> svb   (02.12.10 17:19) [6]

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

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

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

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

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

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

> 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 на уровне логики - все проклял :)