Я имел в виду простое решение вместо такого вот метапрограммирования в SQL-е в непонятную сторону. Т.е., по факту, выкинуть вообще таблицы вида (в данном случае) b_iblock_property, b_iblock_element_property, не стесняться просто править таблицы для получения нужных полей в соответствии с необходимостью портала. Пользователь добавляет свойство к элементу? ОК, вломить ALTER TABLE базы и всё. Удаляет - убрать. Все БД поддерживают сотни полей на таблицу. Часто даже тысячи. Можно еще делать более эффективные индексы потом (или не делать, что тоже важно). И так далее. Ну реально же ну какую базу не возьми, это будет в несколько раз лучше работать, чем вот эти классические словарики. Я этого не видел попросту ни разу. И это типично на мой взгляд тот самый случай. Это не то что денормализация там и т.д., это скорее термины к дизайну базы. Это просто использование возможностей БД по назначению и отказ от странной практики что схема БД это типа всё, лучше убъемся об постоянные JOIN-ы табличек из двух полей, чем её менять. А так-то, конечно, способов оптимизации и без этого решения много. Хотя в mysql навскидку ни одного нормального всё равно не приходит в голову.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2009-12-29 11:22 pm (UTC)Т.е., по факту, выкинуть вообще таблицы вида (в данном случае) b_iblock_property, b_iblock_element_property, не стесняться просто править таблицы для получения нужных полей в соответствии с необходимостью портала. Пользователь добавляет свойство к элементу? ОК, вломить ALTER TABLE базы и всё. Удаляет - убрать. Все БД поддерживают сотни полей на таблицу. Часто даже тысячи. Можно еще делать более эффективные индексы потом (или не делать, что тоже важно). И так далее.
Ну реально же ну какую базу не возьми, это будет в несколько раз лучше работать, чем вот эти классические словарики. Я этого не видел попросту ни разу. И это типично на мой взгляд тот самый случай. Это не то что денормализация там и т.д., это скорее термины к дизайну базы. Это просто использование возможностей БД по назначению и отказ от странной практики что схема БД это типа всё, лучше убъемся об постоянные JOIN-ы табличек из двух полей, чем её менять.
А так-то, конечно, способов оптимизации и без этого решения много. Хотя в mysql навскидку ни одного нормального всё равно не приходит в голову.