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

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

Т.е. для Вас производительность функционала - к функционалу никакого отношения не имеет?

Да, не имеет.
Можно оптимизировать любые сервера/базы независимо от функционала. Разумеется в серверной части. А не клиентской.
4 ноя 14, 15:01    [16796095]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
 		Опять же вы слышали что-нибудь про DWH?
Как видите в этом случае физ. и логическая структура данных очень сильно изменяется как только появляется требование по производительности.
4 ноя 14, 15:04    [16796105]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

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

Т.е. для Вас производительность функционала - к функционалу никакого отношения не имеет?

Да, не имеет.
Можно оптимизировать любые сервера/базы независимо от функционала. Разумеется в серверной части. А не клиентской.


Т.е. когда к Вам придет заказчик и попросит какой-нибудь функционал с обоснованием почему Вы так делаете, вы просто скажете.
А какая разница. Любой функционал потом оптимизируется в серверной части. Так что не волнуйся заказчик.
4 ноя 14, 15:05    [16796111]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Опять же вы слышали что-нибудь про DWH?

Нет, Боже упаси

Павел-П
Как видите в этом случае физ. и логическая структура данных очень сильно изменяется как только появляется требование по производительности.

Вы хотите сказать, что если вы создали стуктуру данных для MSSQL, то она непригодна для других СУБД ?
Мало того, возможна он не будет пригодна для других версиий/редакций того же MSSQL, если в них изменена физическая структура хранения данных ?
4 ноя 14, 15:08    [16796112]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

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

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

Откуда:
Сообщений: 234
Glory
Вы хотите сказать, что если вы создали стуктуру данных для MSSQL, то она непригодна для других СУБД ?
Мало того, возможна он не будет пригодна для других версиий/редакций того же MSSQL, если в них изменена физическая структура хранения данных ?


Отвечаю.

1. Вы хотите сказать, что если вы создали стуктуру данных для MSSQL, то она непригодна для других СУБД ?
Я этого не говорил.
Пжл, найдите, где я это утверждаю в своих предыдущих сообщениях.
2. Мало того, возможна он не будет пригодна для других версиий/редакций того же MSSQL, если в них изменена физическая структура хранения данных ?
Я этого не говорил.
Пжл, найдите, где я это утверждаю в своих предыдущих сообщениях.


А вот Вам вопрос. Вы утверждаете, что OLTP системы и DWH не имеют никаких различий с т.зрения стандартов применяемых для логической и физической организации данных, а также способов их обработки?
4 ноя 14, 15:13    [16796135]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
1. Вы хотите сказать, что если вы создали стуктуру данных для MSSQL, то она непригодна для других СУБД ?
Я этого не говорил.
Пжл, найдите, где я это утверждаю в своих предыдущих сообщениях.

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

Вы упорно несколько раз повторяли, что на ваш функционал напрямую влияет то, как физически хранятся данные в базе.


Павел-П
А вот Вам вопрос. Вы утверждаете, что OLTP системы и DWH не имеют никаких различий с т.зрения стандартов применяемых для логической и физической организации данных, а также способов их обработки?

А вы вообще понимаете разницу между физической и логической организацией данных ?
Как на то, что клиент захотел данные select * from tab1 join tab2, влияет физическая структура хранения данных ? От того, что клиент захотел именно этот запрос, данные физически должны хранится строго "слева-направо" или "по диагонали" ? Потому что в противном случае клиент на сможет сделать select * from tab1 join tab2 ?
4 ноя 14, 15:24    [16796170]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

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

Я смотрю продолжаем задавать вопросы :-).
4 ноя 14, 15:43    [16796271]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

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

Я смотрю продолжаем задавать вопросы :-).

Ну так если вы не понимаете разницу между физ. и лог. моделями, функционалом и производительностью, то о чем еще говорить ?
О том, решит ли наличие какого то поля в индексе проблемы какого-то неизвестного запроса(ов) с производительностью ?
4 ноя 14, 15:46    [16796284]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

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

Еще раз Вам говорю.
К Вам обратился заказчик. Система описана. Предлагайте..., Задавайте вопросы - заказчику (т.е. мне) - Вам ответят.
На выходе физическая структура БД.
Ваши предложения?
4 ноя 14, 15:49    [16796297]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
К Вам обратился заказчик. Система описана. Предлагайте..., Задавайте вопросы - заказчику (т.е. мне) - Вам ответят.

То задавай вопросы, то чего продолжаете задавать вопросы.
Вы сами то определились, что именно вы хотите от сервера ?

Чтобы он вам создал нужный функционал, через правильное физическое расположение данных ?
Или чтобы сервер оптимизировал какой-то запрос, порожденный этим функционалом ?

Сообщение было отредактировано: 4 ноя 14, 15:52
4 ноя 14, 15:52    [16796302]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

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

Я исходные условия задачи описал, если Вам что-то непонятно, спросите.
Мой вопрос - какой бы Вы создавали clustered index и почему в описанном примере выше и желательно почему.
4 ноя 14, 15:56    [16796321]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Мой вопрос - какой бы Вы создавали clustered index и почему в описанном примере выше и желательно почему.

Для системы без запросов на выборку индексы не нужны.
Неужели в это трудно поверить ?
4 ноя 14, 16:00    [16796344]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

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

Да верю я Вам верю. Еще раз Вам говорю, приходит заказчик и говорит. Вот у нас будет такая вот система (online-бухгалтерия) с 1000 клиентов, с примерно вот такими вот процессамию. Представьте, нам пжл, список базовых правил которые вы будете использовать для дизайна БД. И заодно напишите, какие Вы будете создавать clustered index-ы.

А вы в ответ заказчику "Какие clusered index-ы. Для системы без запросов на выборку индексы не нужны."
4 ноя 14, 16:22    [16796432]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Еще раз Вам говорю, приходит заказчик и говорит. Вот у нас будет такая вот система (online-бухгалтерия) с 1000 клиентов, с примерно вот такими вот процессамию. Представьте, нам пжл, список базовых правил которые вы будете использовать для дизайна БД. И заодно напишите, какие Вы будете создавать clustered index-ы.

Ничего я про индексы рассказывать не буду
Потому что они не имеют никакого отношения к процессам.

Павел-П
А вы в ответ заказчику "Какие clusered index-ы. Для системы без запросов на выборку индексы не нужны."

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

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

Ну и на самый первый пост вы тоже ничего ответить\предложить не можете?
Т.е. на него вы тоже ответите "online-бухгалтерия" - это все что угодно.

Если у Вас есть права - удалите все наше предыдущее общение. Оно ничем не поможет окружающему миру. :-)
4 ноя 14, 17:23    [16796646]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Glory
Member

Откуда:
Сообщений: 104760
Павел-П
Ну и на самый первый пост вы тоже ничего ответить\предложить не можете?

Отвечаю в -цатый раз
Для задачи простого хранения данных не нужны никакие индексы.
Задачу физического разделения данных по "организациям" индекс не решит
Других задач вы не ставили.

Павел-П
Если у Вас есть права - удалите все наше предыдущее общение. Оно ничем не поможет окружающему миру. :-)

Эта тема вообще ничем не поможет миру
4 ноя 14, 17:26    [16796666]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 28368
Павел-П
Glory,

Еще раз Вам говорю.
К Вам обратился заказчик. Система описана. Предлагайте..., Задавайте вопросы - заказчику (т.е. мне) - Вам ответят.
На выходе физическая структура БД.
Ваши предложения?
Начинаем задавать вопросы заказчику. О том какие данные есть на данный момент, сколько их, как с ними предполагается работать.
Что будет через год.

Например делать не только кластерный индекс, но и полноценный шардинг по OrganizationId, не имеет смысла, так как организации разные, одни большие, другие маленькие, и данные по такому ключу не удастся равномерно распределить.

У нас к примеру данные 15000 активных организаций в одной бд, а у вас?
4 ноя 14, 17:28    [16796674]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
SERG1257
Member

Откуда:
Сообщений: 2828
 		А у меня была одна компания и эти индексы по OrganizationId только мешали.
4 ноя 14, 17:43    [16796743]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

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

Добрый день.
Можно узнать как Вы храните данные этих 1500 организаций. Вводите organizatiionid в кластерный индекс?
У нас пока 100 другая планируется. Объемы данных сильно большие не планируются.
4 ноя 14, 18:15    [16796880]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Glory
Для задачи простого хранения данных не нужны никакие индексы.


Для задачи простого хранения данных и базы данных не нужны. Хватит плоских файлов. Вы бы мне просто сказали, чтобы я обратился с этим вопросов на форум плоских файлов - сэкономили бы много времени :-)
4 ноя 14, 20:57    [16797555]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34657
Павел-П
Опять же вы слышали что-нибудь про DWH?
Как видите в этом случае физ. и логическая структура данных очень сильно изменяется как только появляется требование по производительности.


Павел, ты глубоко неправ. Не тут конкретно, а вообще.
Glory тебе всё правильно говорит, прислушайся.

Твоё желание разделить данные разных фирм физически бессмысленно -- либо дели помещая в разные БД (вроде бы это ты делать не хочешь,и вполне законно) или не жалуйся, что всё лежит физически смешанно. Оно физически смешанно на уровне страниц в экстентах будет по-любому, на уровне записей на страницах уже не имеет смысла делать, единственное, когда это имеет смысл делать-- сканы индексов по страницам, принадлежащим только одной фирме, но ты это сможешь сделать только для одного индекса в таблице, так что не имеет смысла.
5 ноя 14, 00:11    [16798319]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34657
Павел-П
alexeyvg
пропущено...
Запросы то какие? Если запросы - получить историю по заказу OrderId, то зачем делать кластерный индекс на OrganizationId, и тем более на дату?


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



Давайте попробуем вернуться к сути: а зачем вам надо, чтобы данные разных организаций не были перемешаны физически ?
5 ноя 14, 00:18    [16798352]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
SERG1257
Member

Откуда:
Сообщений: 2828
MasterZiv
Давайте попробуем вернуться к сути: а зачем вам надо, чтобы данные разных организаций не были перемешаны физически ?
Карантин, от вирусов бережется
5 ноя 14, 01:03    [16798451]     Ответить | Цитировать Сообщить модератору
 Re: Совет по дизайну и выбору clustered index  [new]
Ruuu
Member

Откуда: Иркутск
Сообщений: 4272
Павел-П
Соответственно, очень хочется ввести в clustered index идентификатор организации OrganizationId. К сожалению система разрабатывается давно и изначально этот вопрос вообще никто даже не рассматривал. И теперь получается, что физически данные разных организаций лежат на одних и страницах и т.д, и т.п.
Интересно, что скрывается под и т.д, и т.п. ? И что следует из того, что данные лежат на одних страницах, как это может повлиять на доступ одного клиента к данным другого?
Павел-П
Вообщем разрабатывается система, где в одной и той же БД хранится информация разных фирм. При этом они сами же конечно об этом и не догадываются. Ну и каждая организация конечно же читает только свои данные.
Не поверите, но такая ситуация практически в каждой системе, где больше одного клиента. Разграничение доступа к данным реализуется программно.

Если же есть большое желание разнести данные разных клиентов "физически", а отдельные БД сделать нальзя/не хочется, то можете посмотреть в сторону секционирования и файловых групп. Только на безопасность это повлияет чуть менее чем никак, но перед руководством можно будет отчитаться.
5 ноя 14, 09:04    [16798744]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: ←Ctrl  назад   1 [2] 3 4 5   вперед  Ctrl→      все
Все форумы / Microsoft SQL Server Ответить