Программистское

[beldmit]

http://dev.1c-bitrix.ru/community/forums/forum6/topic14898/ - чудный пример нормализации, доведенной до абсурда. Кстати, как такие задачи решать сравнительно честно на чистом SQL - я не знаю, а возникают они регулярно. То есть мне больше всего нравится вариант, когда в чистом SQL такое не решают, а аккуратно берут основные атрибуты из одной таблицы по ключу, дополнительные - по списку уникальных значений из другой, и склеивают в то, что подсовывают пользователю на экран, уже в языке - запросов при этом получается всего 2 компактных.

А еще сегодня мне удалась одна из вещей, за которые я очень люблю свою работу. Маленький патчик - забытый метод класса-потомка в 5 строк, написанный за 15 минут после часового анализа кода, решил одну нашу застарелую проблему. У клиентов жалоб должно поуменьшиться.

А вот в изучении питона пока застрял. Что, впрочем, естественно: возвращаюсь поздно и со съеденными мозгами. А в той задачке, которую я ковыряю, не придумал пока алгоритмов. Сам язык мне скорее понравился, причем именно выравниванием пробелами, которое у меня вызывало отторжение. Код выглядит воздушным. Странности у языка тоже есть, ну да ладно.

Comments

[beldmit.livejournal.com]

Честно говоря, не понял, какое решение вы имеете в виду под динамическим созданием таблиц. Временная таблица под нужды запроса?

Способов, альтернативных приведенному в пример, я сходу расскажу штук 5, если что :-)

[dmih.livejournal.com]

Я имел в виду простое решение вместо такого вот метапрограммирования в SQL-е в непонятную сторону.
Т.е., по факту, выкинуть вообще таблицы вида (в данном случае) b_iblock_property, b_iblock_element_property, не стесняться просто править таблицы для получения нужных полей в соответствии с необходимостью портала. Пользователь добавляет свойство к элементу? ОК, вломить ALTER TABLE базы и всё. Удаляет - убрать. Все БД поддерживают сотни полей на таблицу. Часто даже тысячи. Можно еще делать более эффективные индексы потом (или не делать, что тоже важно). И так далее.
Ну реально же ну какую базу не возьми, это будет в несколько раз лучше работать, чем вот эти классические словарики. Я этого не видел попросту ни разу. И это типично на мой взгляд тот самый случай. Это не то что денормализация там и т.д., это скорее термины к дизайну базы. Это просто использование возможностей БД по назначению и отказ от странной практики что схема БД это типа всё, лучше убъемся об постоянные JOIN-ы табличек из двух полей, чем её менять.
А так-то, конечно, способов оптимизации и без этого решения много. Хотя в mysql навскидку ни одного нормального всё равно не приходит в голову.

[beldmit.livejournal.com]

Да, такой вариант понятен. Обладает одним недостатком: не для человеческого понимания таблица более, чем в 30 колонок :-). По простоте запросов, впрочем, бьет все. Подозреваю некоторый overhead в обрабатывающем коде, но вряд ли фатальный.

А MySQL не поддерживает XML как тип данных? В PostgreSQL помойку можно запихнуть в XML, а плоскую помойку - в HStore...

[dmih.livejournal.com]

А собственно я немного преднавогодне туплю: у них это есть, и в данной ссылке они это и предлагают.