Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 5 вперед Ctrl→ все |
Glory Member Откуда: Сообщений: 104760 |
Да, не имеет. Можно оптимизировать любые сервера/базы независимо от функционала. Разумеется в серверной части. А не клиентской. |
||
4 ноя 14, 15:01 [16796095] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Опять же вы слышали что-нибудь про DWH? Как видите в этом случае физ. и логическая структура данных очень сильно изменяется как только появляется требование по производительности. |
4 ноя 14, 15:04 [16796105] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Т.е. когда к Вам придет заказчик и попросит какой-нибудь функционал с обоснованием почему Вы так делаете, вы просто скажете. А какая разница. Любой функционал потом оптимизируется в серверной части. Так что не волнуйся заказчик. |
||||
4 ноя 14, 15:05 [16796111] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Нет, Боже упаси
Вы хотите сказать, что если вы создали стуктуру данных для MSSQL, то она непригодна для других СУБД ? Мало того, возможна он не будет пригодна для других версиий/редакций того же MSSQL, если в них изменена физическая структура хранения данных ? |
||||
4 ноя 14, 15:08 [16796112] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Не ставьте с ног на голову. Я сказал, что физическая стуктура хранения данных не влияет на функционал. А не то, что физическая структура пораждает функционал или выправляет его кривизну. |
||
4 ноя 14, 15:10 [16796121] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Отвечаю. 1. Вы хотите сказать, что если вы создали стуктуру данных для MSSQL, то она непригодна для других СУБД ? Я этого не говорил. Пжл, найдите, где я это утверждаю в своих предыдущих сообщениях. 2. Мало того, возможна он не будет пригодна для других версиий/редакций того же MSSQL, если в них изменена физическая структура хранения данных ? Я этого не говорил. Пжл, найдите, где я это утверждаю в своих предыдущих сообщениях. А вот Вам вопрос. Вы утверждаете, что OLTP системы и DWH не имеют никаких различий с т.зрения стандартов применяемых для логической и физической организации данных, а также способов их обработки? |
||
4 ноя 14, 15:13 [16796135] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Вы упорно несколько раз повторяли, что на ваш функционал напрямую влияет то, как физически хранятся данные в базе.
Вы упорно несколько раз повторяли, что на ваш функционал напрямую влияет то, как физически хранятся данные в базе.
А вы вообще понимаете разницу между физической и логической организацией данных ? Как на то, что клиент захотел данные select * from tab1 join tab2, влияет физическая структура хранения данных ? От того, что клиент захотел именно этот запрос, данные физически должны хранится строго "слева-направо" или "по диагонали" ? Потому что в противном случае клиент на сможет сделать select * from tab1 join tab2 ? |
||||||
4 ноя 14, 15:24 [16796170] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Glory, Я смотрю продолжаем задавать вопросы :-). |
4 ноя 14, 15:43 [16796271] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Ну так если вы не понимаете разницу между физ. и лог. моделями, функционалом и производительностью, то о чем еще говорить ? О том, решит ли наличие какого то поля в индексе проблемы какого-то неизвестного запроса(ов) с производительностью ? |
||
4 ноя 14, 15:46 [16796284] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Glory, Еще раз Вам говорю. К Вам обратился заказчик. Система описана. Предлагайте..., Задавайте вопросы - заказчику (т.е. мне) - Вам ответят. На выходе физическая структура БД. Ваши предложения? |
4 ноя 14, 15:49 [16796297] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
То задавай вопросы, то чего продолжаете задавать вопросы. Вы сами то определились, что именно вы хотите от сервера ? Чтобы он вам создал нужный функционал, через правильное физическое расположение данных ? Или чтобы сервер оптимизировал какой-то запрос, порожденный этим функционалом ? Сообщение было отредактировано: 4 ноя 14, 15:52 |
||
4 ноя 14, 15:52 [16796302] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Glory, Я исходные условия задачи описал, если Вам что-то непонятно, спросите. Мой вопрос - какой бы Вы создавали clustered index и почему в описанном примере выше и желательно почему. |
4 ноя 14, 15:56 [16796321] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Для системы без запросов на выборку индексы не нужны. Неужели в это трудно поверить ? |
||
4 ноя 14, 16:00 [16796344] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Glory, Да верю я Вам верю. Еще раз Вам говорю, приходит заказчик и говорит. Вот у нас будет такая вот система (online-бухгалтерия) с 1000 клиентов, с примерно вот такими вот процессамию. Представьте, нам пжл, список базовых правил которые вы будете использовать для дизайна БД. И заодно напишите, какие Вы будете создавать clustered index-ы. А вы в ответ заказчику "Какие clusered index-ы. Для системы без запросов на выборку индексы не нужны." |
4 ноя 14, 16:22 [16796432] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Ничего я про индексы рассказывать не буду Потому что они не имеют никакого отношения к процессам.
Именно так. Потому что "online-бухгалтерией" можно назвать что угодно. |
||||
4 ноя 14, 16:27 [16796449] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Glory, Ну и на самый первый пост вы тоже ничего ответить\предложить не можете? Т.е. на него вы тоже ответите "online-бухгалтерия" - это все что угодно. Если у Вас есть права - удалите все наше предыдущее общение. Оно ничем не поможет окружающему миру. :-) |
4 ноя 14, 17:23 [16796646] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104760 |
Отвечаю в -цатый раз Для задачи простого хранения данных не нужны никакие индексы. Задачу физического разделения данных по "организациям" индекс не решит Других задач вы не ставили.
Эта тема вообще ничем не поможет миру |
||||
4 ноя 14, 17:26 [16796666] Ответить | Цитировать Сообщить модератору |
skyANA Member Откуда: Зеленоград Сообщений: 28368 |
Что будет через год. Например делать не только кластерный индекс, но и полноценный шардинг по OrganizationId, не имеет смысла, так как организации разные, одни большие, другие маленькие, и данные по такому ключу не удастся равномерно распределить. У нас к примеру данные 15000 активных организаций в одной бд, а у вас? |
||
4 ноя 14, 17:28 [16796674] Ответить | Цитировать Сообщить модератору |
SERG1257 Member Откуда: Сообщений: 2828 |
А у меня была одна компания и эти индексы по OrganizationId только мешали. |
4 ноя 14, 17:43 [16796743] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
skyANA, Добрый день. Можно узнать как Вы храните данные этих 1500 организаций. Вводите organizatiionid в кластерный индекс? У нас пока 100 другая планируется. Объемы данных сильно большие не планируются. |
4 ноя 14, 18:15 [16796880] Ответить | Цитировать Сообщить модератору |
Павел-П Member Откуда: Сообщений: 234 |
Для задачи простого хранения данных и базы данных не нужны. Хватит плоских файлов. Вы бы мне просто сказали, чтобы я обратился с этим вопросов на форум плоских файлов - сэкономили бы много времени :-) |
||
4 ноя 14, 20:57 [16797555] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Павел, ты глубоко неправ. Не тут конкретно, а вообще. Glory тебе всё правильно говорит, прислушайся. Твоё желание разделить данные разных фирм физически бессмысленно -- либо дели помещая в разные БД (вроде бы это ты делать не хочешь,и вполне законно) или не жалуйся, что всё лежит физически смешанно. Оно физически смешанно на уровне страниц в экстентах будет по-любому, на уровне записей на страницах уже не имеет смысла делать, единственное, когда это имеет смысл делать-- сканы индексов по страницам, принадлежащим только одной фирме, но ты это сможешь сделать только для одного индекса в таблице, так что не имеет смысла. |
||
5 ноя 14, 00:11 [16798319] Ответить | Цитировать Сообщить модератору |
MasterZiv Member Откуда: Питер Сообщений: 34657 |
Давайте попробуем вернуться к сути: а зачем вам надо, чтобы данные разных организаций не были перемешаны физически ? |
||||
5 ноя 14, 00:18 [16798352] Ответить | Цитировать Сообщить модератору |
SERG1257 Member Откуда: Сообщений: 2828 |
![]() |
||
5 ноя 14, 01:03 [16798451] Ответить | Цитировать Сообщить модератору |
Ruuu Member Откуда: Иркутск Сообщений: 4272 |
Если же есть большое желание разнести данные разных клиентов "физически", а отдельные БД сделать нальзя/не хочется, то можете посмотреть в сторону секционирования и файловых групп. Только на безопасность это повлияет чуть менее чем никак, но перед руководством можно будет отчитаться. |
||||
5 ноя 14, 09:04 [16798744] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 [2] 3 4 5 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |