axdaily: Surrogate keys in AX 2012

[Logger]

Цитата:

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

Уверен, что в пресс-релизах о выходе DAX2012 будет много сообщений о росте производительности в n раз. Вопрос в том, на какой выборке будет достигнута эта производительность и насколько типична эта выборка для того самого upper midmarket, для которого предназначена аксапта...

Именно !
Думаю в этом все дело.
Т.е. вопрос в том на какой рынок хотят вывести Аксапту. У меня складывается ощущение что MS хочет замахнуться на рынок SAP (плох солдат который не мечтает стать генералом. Нафига было вообще лезть на этот рынок, если не стремиться стать на нем лидером ?), т.е. для upper midmarket оставят Navision и может еще что, а Аксапту двинут на крупняк.

Мы с вами свои рассуждения строим для баз размером 10 - 100 - 1000 гигов. (А больше под аксаптой наверно и не бывает пока) А её возможно готовят для больших объемов баз. Тогда понятно желание ввести суррогатные ключи (читай сэкономить память БД и ускорить время работы с индексами).

Кстати, пример про 20 байт не очень удачный. Большинство ключей, по которым идет фильтрация и объединение таблиц являются наследниками EDT NUM, который имеет длину 20 символов, т.е. 40 байт в юникоде. Т.е. разница в 5 раз,а не в 2,5 раза.

[fed]

Цитата:

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

Именно !
Думаю в этом все дело.
Т.е. вопрос в том на какой рынок хотят вывести Аксапту. У меня складывается ощущение что MS хочет замахнуться на рынок SAP (плох солдат который не мечтает стать генералом.

Боюсь - для этого недостаточно введения поддержки суррогатных ключей, наследования таблиц и ивентинга
Для этого надо понимать как клиентский бизнес работает и от этого строить и маркетинг, и продажи, и разработку, и работу с партнерами.А вот в этом направлении движений не намечается. Присутствует наивная вера, что партнеры (у которых не так чтобы уж дофига денег), вдруг вложатся в разработку вертикальных решений и разовьют отраслевую эскпертизу. А раньше они, конечно-же, не хотели этого делать исключительно из за отсутствия суррогатных ключей в Аксапте
Опять улучшения из серии - "They are barking at the wrong tree"

[Logger]

Цитата:

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

Боюсь - для этого недостаточно введения поддержки суррогатных ключей, наследования таблиц и ивентинга ...

С этим не поспоришь

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

[fed]

Цитата:

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

Кстати, пример про 20 байт не очень удачный. Большинство ключей, по которым идет фильтрация и объединение таблиц являются наследниками EDT NUM, который имеет длину 20 символов, т.е. 40 байт в юникоде. Т.е. разница в 5 раз,а не в 2,5 раза.

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

[Logger]

Цитата:

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

...все равно в реальной жизни почти все данные в кэше, а при чтении из памяти, выигрыш из за экономии места для типичного объема данных - небольшой.

Это все верно.
Но я подумал о том что возможно Аксапту готовят для работы в более жестких условиях. Потому что извините - когда у вас полбазы влезает в оперативку сервера БД, то это тепличные условия. Можно вообще про оптимизации не думать, а ковырять в носу весь день.

[fed]

Цитата:

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

Это все верно.
Но я подумал о том что возможно Аксапту готовят для работы в более жестких условиях. Потому что извините - когда у вас полбазы влезает в оперативку сервера БД, то это тепличные условия. Можно вообще про оптимизации не думать, а ковырять в носу весь день.

Стоимость 4 гигов серверной памяти Kingston - порядка 120 евро. Стоимость работы специалиста по производительности (в Германии) - 120 евро за час
Вообще вся реляционная теория писалась в те времена когда годовая зарплата спеца была в районе 30000, а стоимость VAX средней руки - 500000. Память была дорогой, а диски медленными. Теперь вон, в новой версии Power Pivot (которая в Denali должна быть интегрирована в SQL Server), на полном серьезе собираются почти всю базу держать в оперативке в сжатом виде. Вообще - может оказаться что привычный B-Tree уже не эффективен для хранения данных, потому что данные храняться, как правило, не на диске, а в памяти, и принятое в B-Tree деление на страницы больше не актуально (поскольку чтение идет побайтно, а не постранично).
Это я к тому, что фундаментальные книжки про проектированию БД (Типа Дейта, которого я все равно уважаю), несколько устарели. Соответственно - молиться на все эти нормальные формы и суррогатные ключи - поздновато...