Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Добрый вечер,

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

Соответственно, очень хочется ввести в clustered index идентификатор организации OrganizationId. К сожалению система разрабатывается давно и изначально этот вопрос вообще никто даже не рассматривал. И теперь получается, что физически данные разных организаций лежат на одних и страницах и т.д, и т.п.

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

OrganizationId UniqueIdentifier
OrderId UniqueIdentifier
StatusId SMALLINT
StatusDateTime DATETIME

Вообщем сейчас видятся следующие варианты.
Вариант 1.
1. Clustered index на OrganizationId, StatusDate
2. Primary key на OrderId, StatusDateTime

Вариант 2.
1. Добавить колонку OrderStatusEventId bigint identity. Сделать ее только primary key (есть вероятность, что в будущем на эту таблицу будут foreign key, составных FK бы не хотелось)
2. Clustered index на OrganizationId и OrderStatusEventId
3. На OrderId, StatusDateTime надо бы навесить unique key constraint.

Вариант 3.
1. Добавить колонку OrderStatusEventId bigint identity. Сделать ее только primary key (есть вероятность, что в будущем на эту таблицу будут foreign key, составных FK бы не хотелось)
2. Clustered index на OrganizationId и StatusDateTime
3. На OrderId, StatusDateTime надо бы навесить unique key constraint.
Не может быть 2-ух событий на одно время.

С учетом малой вероятности наличия FK пока склоняюсь к первому варианту.
Данные в таблицу будут часто вставляться. Поэтому перестроения clustered index хотелось бы избежать. И данные хотелось бы, чтобы физически не перемешивались для разных OrganizationId

Любые подсказки и замечания - приветствуются.
3 ноя 14, 20:37    [16793632]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31438
Павел-П
Вообщем сейчас видятся следующие варианты.
Вариант 1.
1. Clustered index на OrganizationId, StatusDate
2. Primary key на OrderId, StatusDateTime
Запросы то какие? Если запросы - получить историю по заказу OrderId, то зачем делать кластерный индекс на OrganizationId, и тем более на дату?
3 ноя 14, 20:47    [16793683]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
alexeyvg
Павел-П
Вообщем сейчас видятся следующие варианты.
Вариант 1.
1. Clustered index на OrganizationId, StatusDate
2. Primary key на OrderId, StatusDateTime
Запросы то какие? Если запросы - получить историю по заказу OrderId, то зачем делать кластерный индекс на OrganizationId, и тем более на дату?



Ну кластерный индекс определятся не только запросами, но и тем как информация пишется (в какой последовательности).
Запросы разные. Конечно и мелкие есть, как Вы написали. Но и поднять статус всех Ордеров на дату будет нужно.
3 ноя 14, 21:01    [16793746]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
alexeyvg
Павел-П
Вообщем сейчас видятся следующие варианты.
Вариант 1.
1. Clustered index на OrganizationId, StatusDate
2. Primary key на OrderId, StatusDateTime
Запросы то какие? Если запросы - получить историю по заказу OrderId, то зачем делать кластерный индекс на OrganizationId, и тем более на дату?


ну и еще раз уточню. Есть жаление, чтобы данные разных организаций не были перемешены физически на страницах. Если OrganizationId не введете в кластерный индекс - то этого не добиться.
3 ноя 14, 21:03    [16793751]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Павел-П
Есть жаление, чтобы данные разных организаций не были перемешены физически на страницах


окак! интересное требование.
3 ноя 14, 23:42    [16794602]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Crimean
Павел-П
Есть жаление, чтобы данные разных организаций не были перемешены физически на страницах


окак! интересное требование.


ну просто есть единая система, которая держит данные разных организаций, но сами то организации не знают, что все их данные лежат в одной БД. Такая вот 1С бухгалтерия, только не для одного предприятия, а для многих. Да еще и организаций много и работают в параллельно. Если их транзакции перемешивать, то потом много лишний данных читать. А каждый запрос на чтение, работает только с данными одной организации всегда.

Честно говоря, мне кажется, что требование довольно логичное.
4 ноя 14, 00:03    [16794661]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Павел-П,

а зачем для этого одна база данных? может каждой организации - по своей базе?
4 ноя 14, 00:10    [16794686]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Crimean,

А зачем иметь разные БД? Система единая, структура единая.
Хотите для 1000 клиентов - 1000 промоушенов делать?
4 ноя 14, 00:13    [16794696]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Crimean,

Да и жить начинаем вроде бы в век облачных технологий. Сейчас таких сервисов очень много. Прикиньте, если каждому клиенту online-бухгалтерии базу данных создавать.
4 ноя 14, 00:22    [16794721]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
ну просто есть единая система, которая держит данные разных организаций, но сами то организации не знают, что все их данные лежат в одной БД. Такая вот 1С бухгалтерия, только не для одного предприятия, а для многих. Да еще и организаций много и работают в параллельно. Если их транзакции перемешивать, то потом много лишний данных читать. А каждый запрос на чтение, работает только с данными одной организации всегда.

Честно говоря, мне кажется, что требование довольно логичное.

А вас не пугает, что на дисковом массиве страницы разных фирм тоже могут быть "перемешаны" ?
4 ноя 14, 09:21    [16795202]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory
А вас не пугает, что на дисковом массиве страницы разных фирм тоже могут быть "перемешаны" ?


Скажем так я это понимаю. Вы мне можете предложить что-нибудь, чтобы этого избежать?
4 ноя 14, 11:14    [16795401]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory,

Я собственно и пытаюсь понять, какую лучше политику применять с учетом того, что данные разных организаций и храняться в одной БД.
4 ноя 14, 13:02    [16795687]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Скажем так я это понимаю. Вы мне можете предложить что-нибудь, чтобы этого избежать?

Если у вас физическое расположение данных как-то влияет на функционал, то 16794686
4 ноя 14, 13:27    [16795741]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory,

Это ответ из разряда масло-масляное.
Физическое расположение данных всегда влияет на функционал. Причем в той же степени как фундамент здания влияет на само здание.

Мой же вопрос - стоит ли заморачиваться введением Organizationid в clustered index. И получу ли я от этого что-либо полезное.
4 ноя 14, 13:50    [16795804]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Физическое расположение данных всегда влияет на функционал.Причем в той же степени как фундамент здания влияет на само здание.

Да что вы говорите ?
Т.е. стоит мне расположить данные по фен-шую и у меня срезу появитяс/заработает нужный функционал ?

Павел-П
Мой же вопрос - стоит ли заморачиваться введением Organizationid в clustered index. И получу ли я от этого что-либо полезное.

Индексы делаются для достижения какой-то цели.
Если ваша цель - это физическое отделение одних данных от других, то индексы ее не рашают.
4 ноя 14, 13:54    [16795812]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory,

1. Я свою цель описал. Теперь пытаюсь понять, можно ли ее реализовать какими-то средствами в представленных условиях задачи.
И стоит ли это вообще делать. Или тупо хранить данные организаций в перемешку.
На данный момент я вижу преймущества от того, что данные будут лежать более скомпановано на страницах. Читаться они быстрее будут.

2. "Т.е. стоит мне расположить данные по фен-шую и у меня срезу появитяс/заработает нужный функционал ?"
Мой функционал будет работать и в первой и во второй случае.
Впрочем как и ваш.
Только вот на каких-то операциях быстрее, а на каких-то медленнее.

3. Собственно вопрос в том, что я ищу каких-нибудь советов касательно на что обратить внимание для моей структуры. Собственно понимания, нужно ли заморачиваться этим или забить.
4 ноя 14, 14:19    [16795920]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Или тупо хранить данные организаций в перемешку.На данный момент я вижу преймущества от того, что данные будут лежать более скомпановано на страницах. Читаться они быстрее будут.

Вы вообще знакомы с физической структурой индексов/куч в MSSQL ?

Павел-П
Только вот на каких-то операциях быстрее, а на каких-то медленнее.

Это вы виртуальные замеры сделали что ли ? Когда все другие оптимизации выполнены ?
И проблема только в том, что на одной странице данных лежат разные значения OrganizationId ?

Павел-П
Мой функционал будет работать и в первой и во второй случае.
Впрочем как и ваш.

Т.е. все таки на функционал физическое размещение данных не влияет ?

Павел-П
3. Собственно вопрос в том, что я ищу каких-нибудь советов касательно на что обратить внимание для моей структуры. Собственно понимания, нужно ли заморачиваться этим или забить.

В вашей структуре нет ничего уникального
4 ноя 14, 14:32    [16795968]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory
Т.е. все таки на функционал физическое размещение данных не влияет ?


Glory, т.е. фундамент здания на дальнейшее поведение стен влияния не оказывает?
4 ноя 14, 14:42    [16796007]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Glory, т.е. фундамент здания на дальнейшее поведение стен влияния не оказывает?

Мля.
По-вашему, на поведение ваших стен оказывает влияние вода, которая использовалась при изготовлении бетона, который пошел в фундамент.
4 ноя 14, 14:45    [16796019]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory
В вашей структуре нет ничего уникального


Так можно услышать, как подобные вопросы решались на таких неуникальных структурах. Если они просто игнорировались, то это тоже ответ.


Glory
Это вы виртуальные замеры сделали что ли ? Когда все другие оптимизации выполнены ?
И проблема только в том, что на одной странице данных лежат разные значения OrganizationId ?


Собственно говоря да. А какие вы еще оптимизации сможете сделать? Индексы у Вас будут одинаковые для всех оптимизаций. Физическая структура таблицы же не меняется (колонки одинаковые). Данные тоже хранятся одни и те же.
4 ноя 14, 14:47    [16796027]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
А какие вы еще оптимизации сможете сделать? И

Для того, чтобы что-то оптимизировать, нужно сначала найти это что-то

Павел-П
Индексы у Вас будут одинаковые для всех оптимизаций. Физическая структура таблицы же не меняется (колонки одинаковые). Данные тоже хранятся одни и те же.

Для _хранения_ данных вообще никакая оптимизация не нужна. А все индексы вообще вредны.
4 ноя 14, 14:50    [16796044]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory,

Хорошо еще раз перефразируем еще раз вопрос.
Т.е. вы утверждаете, что физическое хранение данных ни на какой функционал в дальнейшем влияние никак оказывать не будет?
4 ноя 14, 14:51    [16796054]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Т.е. вы утверждаете, что физическое хранение данных ни на какой функционал в дальнейшем влияние никак оказывать не будет?

На функционал - никакого.
Потому что функционал и производительность - это разные вещи.
4 ноя 14, 14:54    [16796066]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory
Для того, чтобы что-то оптимизировать, нужно сначала найти это что-то


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

А вы ему. Системы нет, данных еще нет. Давайте сначала сделаем как-нибудь, а потом посмотрим, как лучше будет...
4 ноя 14, 14:56    [16796075]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory,

Т.е. для Вас производительность функционала - к функционалу никакого отношения не имеет?
4 ноя 14, 14:57    [16796081]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить