Индексы таблицы InventSettlement

[sukhanchik]

Цитата:

Сообщение от Kabardian

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

А вот это как раз не страшно. Что на первом месте - производительность или размер БД? Да и железки под хранение БД не такие уж и дорогие.
Microsoft вон пошел в АХ 2012 по пути нормализации и кучи джойнов. Но это заведомо даст проигрыш в производительности на том же оборудовании.
Так что тут как раз переживать не стоит.

[Kabardian]

Цитата:

Сообщение от sukhanchik

А вот это как раз не страшно. Что на первом месте - производительность или размер БД?

Стыдно признать, но иногда при неудачном стечении обстоятельств размер БД становится на первое место. Например, мы работаем по франшизе, вся инсталляция AX на аутсорсинге и внезапно решили расторгнуть отношения с франчайзером. Согласование и выполнение работ по увеличению системных ресурсов (установка дополнительного AOS, увеличение места на жестком диске и т. д.) может растянуться на долгие месяцы, т. к. франчайзер ставит палки в колеса.

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

[Владимир Максимов]

Цитата:

Сообщение от sukhanchik

А вот это как раз не страшно. Что на первом месте - производительность или размер БД?

Закрытие склада обычно выполняется раз в месяц или еще реже. Если будет тормозить, то это печально, конечно, но раз в месяц можно и потерпеть. А вот насчет размера...

Цитата:

Сообщение от sukhanchik

Да и железки под хранение БД не такие уж и дорогие.

Мне бы Вашу уверенность. Если посчитать совокупные расходы, то железки вообще золотые оказываются. Кроме того, очень больша проблема убедить руководство что-то закупить из железок, особенно если проблему можно решить уменьшив размер данных.

Цитата:

Сообщение от sukhanchik

Microsoft вон пошел в АХ 2012 по пути нормализации и кучи джойнов. Но это заведомо даст проигрыш в производительности на том же оборудовании.

Это общая политика Microsoft. Если не ошибаюсь, где-то в статьях Джоэля Спольски вычитал чем они руководствуются. Дескать пока будешь оптимизировать код, железо разовьется настолько, что его производительность перекроет потери от не оптимального кода. Тогда какой смысл оптимизировать?

Цитата:

Сообщение от sukhanchik

Так что тут как раз переживать не стоит.

Еще как стоит. Я вот сейчас начал очередной цикл борьбы за свободное место на диске. Опять места не хватает (кое-что освободил, но этого хватит максимум на 1 год). А закупить - никто денег не дает

[sukhanchik]

Цитата:

Сообщение от Владимир Максимов

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

Ну... все ж упирается в конкретное время. Смотря сколько занимает процесс закрытия. Если сутки или меньше - то без проблем. Если больше - то уже сложнее. Опять-таки - вопрос убеждения руководства. Докупить диски (массив) обычно все же дешевле выходит, нежели новый сервер.
Плюс еще момент. Объем данных, который дают индексы может быть на порядок меньше объема данных, который можно потереть без последствий для системы (InventSumTTSLog, *ParmTable, *ParmLine и т.д.). Поэтому тут надо все взвешивать.

Цитата:

Сообщение от Владимир Максимов

Это общая политика Microsoft. Если не ошибаюсь, где-то в статьях Джоэля Спольски вычитал чем они руководствуются. Дескать пока будешь оптимизировать код, железо разовьется настолько, что его производительность перекроет потери от не оптимального кода. Тогда какой смысл оптимизировать?

Идея логичная, только в случае АХ2012 речь идет о сознательной перестройке системы, а не о написании неоптимального кода.
А в целом - согласен, но с оговоркой. Какой бы высокопроизводительный сервер не был - все равно на нем можно сделать мертвую блокировку. А это означает, что идеала никогда не достичь - и все равно оптимизацию до определенного уровня нужно поддерживать. (Правило 80%/20%).
Опять-таки - начальство охотнее пойдет на апгрейд системы, если он потребует минимальных затрат (особенно на железки)

[Владимир Максимов]

Цитата:

Сообщение от sukhanchik

Ну... все ж упирается в конкретное время. Смотря сколько занимает процесс закрытия. Если сутки или меньше - то без проблем. Если больше - то уже сложнее.

Это, конечно... Вопрос приоритетов...

Цитата:

Сообщение от sukhanchik

Опять-таки - вопрос убеждения руководства. Докупить диски (массив) обычно все же дешевле выходит, нежели новый сервер.

Не все так просто как кажется

Диски лежат не сами по себе, а в стойке (полке). А стойки закупаются далеко не каждый год. А через пару лет найти диски нужной марки для конкретной стойки - уже проблема. "Антиквариат", понимаешь ли Значит, надо закупать уже и новые стойки к новым дискам или искать "антикварные" диски по очень дополнительной цене.

Это со стороны железа. Теперь смотрим со стороны администратора.

Кроме самой базы нужен еще BackUp. Затем нужна база для разработки. Еще одна база для тестирования. Идельный вариант, иметь еще одну копию базы. А еще может быть база для отчетов. А еще копии базы отчетов. А еще...

Вот и получается, что нужно докупать, минимум, в 5-кратном размере. Ну, т.е. если надо 100ГБ на рабочую базу, значит, придется раскошелится на 500ГБ для дополнительных копий базы.

В общем, хочешь получить "мелочь", но вокруг этой "мелочи" возникает масса дополнительных условий.

Цитата:

Сообщение от sukhanchik

Плюс еще момент. Объем данных, который дают индексы может быть на порядок меньше объема данных, который можно потереть без последствий для системы (InventSumTTSLog, *ParmTable, *ParmLine и т.д.). Поэтому тут надо все взвешивать.

Ну, в данном случае речь идет о вполне конкретной таблице InventSettlement. А у нее объем данных и объем индекса примерно равны.

Цитата:

Сообщение от sukhanchik

Опять-таки - начальство охотнее пойдет на апгрейд системы, если он потребует минимальных затрат (особенно на железки)

Это в теории. На практике так не получается. Суммарные (итоговые) затраты обычно очень велики. Но вот если удастся разбить затраты на части (этапы внедрения или этапы обновления), то вот в этом случае пробивать легче. Разовый платеж относительно небольшой, а что там по итогам года (или нескольких лет) - уже другой вопрос Проблема как раз в том и состоит, что процесс увеличение дискового пространства на части не делится. "Я бы взял частями, но мне нужно сразу" (с)