AX 2012 Наследование таблиц. Краткое описание механизма

[niksen]

Цитата:

Производительность АХ 2012 (впрочем, как и ожидалось при нормализации СУБД) упирается не столько в мощности процессора / памяти - сколько в скорость дисков и операций чтения/записи.

вывод такой интересный, я конечно не упираюсь в реляционную теорию бд, но при нормализации субд разве всё начинает зависеть от скорости хардов? может я как-то не так логику понимаю, но, допустим ненормализованная бд, в ней 3 таблицы, в каждой из которых допустим 1000 записей по 30 полей в каждом, то есть перебирается 30 000 значений ячеек в сумме 1000 строк, и нормализованная, в которой будет например 15 таблиц, но полей в каждой таблице будет гораздо меньше, то есть перелопачивание данных будет меньше, разве не так?

[sukhanchik]

Цитата:

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

вывод такой интересный, я конечно не упираюсь в реляционную теорию бд, но при нормализации субд разве всё начинает зависеть от скорости хардов? может я как-то не так логику понимаю, но, допустим ненормализованная бд, в ней 3 таблицы, в каждой из которых допустим 1000 записей по 30 полей в каждом, то есть перебирается 30 000 значений ячеек в сумме 1000 строк, и нормализованная, в которой будет например 15 таблиц, но полей в каждой таблице будет гораздо меньше, то есть перелопачивание данных будет меньше, разве не так?

"Все - нехорошее слово" (с). При нормализации - скорость хардов заведомо начинает играть бОльшую роль, нежели чем при денормализации.
Причина 1. Когда мы пишем Х++ - обычно мы пишем запрос типа SELECT *, т.е. заведомо выбираем ВСЕ поля - сколько бы их ни было. Т.е. если нам нужно выбрать строку накладной, код клиента и группу клиента, то при денормализации, в которой группа клиентов сидит в накладной - мы не джойним всю таблицу клиентов и производим выборку только всех полей накладной. Если же в накладной нужных нам полей нет, то мы джойним таблицу клиентов и выбираем все поля из этой таблицы - т.е. хотим мы или нет - но выбираем мы больше полей.
В случае разбиения большой таблицы на маленькие - появляются дополнительные поля - связки, которые тоже подлежат выборке.
Причина 2. Индексы. Сколько бы ни было полей в таблице - поиск осуществляется по индексу, а не по Вашему алгоритму (не так часто требуется получить большой набор данных - сколько требуется найти записи, удовлетворяющие некоему критерию отбора).
Причина 3 (следствие). Джойны всегда работают заведомо медленнее, чем выборка из одной таблицы. Плюс LEFT JOIN на порядок тормознутее INNER JOIN.
Причина 4. Данные таблицы можно дефрагментировать внутри файла. А гарантировать, что нужные таблицы при выборке будут находиться рядом друг другом в файле БД - нельзя. Т.е. джойн - это еще дополнительная работа для диска.