![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программистское
http://dev.1c-bitrix.ru/community/forums/forum6/topic14898/ - чудный пример нормализации, доведенной до абсурда. Кстати, как такие задачи решать сравнительно честно на чистом SQL - я не знаю, а возникают они регулярно. То есть мне больше всего нравится вариант, когда в чистом SQL такое не решают, а аккуратно берут основные атрибуты из одной таблицы по ключу, дополнительные - по списку уникальных значений из другой, и склеивают в то, что подсовывают пользователю на экран, уже в языке - запросов при этом получается всего 2 компактных.
А еще сегодня мне удалась одна из вещей, за которые я очень люблю свою работу. Маленький патчик - забытый метод класса-потомка в 5 строк, написанный за 15 минут после часового анализа кода, решил одну нашу застарелую проблему. У клиентов жалоб должно поуменьшиться.
А вот в изучении питона пока застрял. Что, впрочем, естественно: возвращаюсь поздно и со съеденными мозгами. А в той задачке, которую я ковыряю, не придумал пока алгоритмов. Сам язык мне скорее понравился, причем именно выравниванием пробелами, которое у меня вызывало отторжение. Код выглядит воздушным. Странности у языка тоже есть, ну да ладно.
А еще сегодня мне удалась одна из вещей, за которые я очень люблю свою работу. Маленький патчик - забытый метод класса-потомка в 5 строк, написанный за 15 минут после часового анализа кода, решил одну нашу застарелую проблему. У клиентов жалоб должно поуменьшиться.
А вот в изучении питона пока застрял. Что, впрочем, естественно: возвращаюсь поздно и со съеденными мозгами. А в той задачке, которую я ковыряю, не придумал пока алгоритмов. Сам язык мне скорее понравился, причем именно выравниванием пробелами, которое у меня вызывало отторжение. Код выглядит воздушным. Странности у языка тоже есть, ну да ладно.
no subject
Человека, это написавшего, хочется повесить за яйца. Желательно, чтобы они оторвались, дабы не размножался.
no subject
no subject
no subject
знал бы ты, сколько я таких патчиков в своё время нашел-сделал ... типа, блин, внутреннего запроса с теми же именами полей, вставленный кем-то из джуниоров по критику или еще какого украшательства, после чего регулярный процесс перестал в 20% случаев работать ...
no subject
Предесть патча на самом деле не в том, что он фиксит баг - это было бы не так прикольно. Просто с нуля пишется метод - и все, финита. Кайф же!
no subject
no subject
no subject
no subject
no subject
no subject
Для меня до сих пор загадка, почему такой простой, прямолинейный, качественный, эффективный способ не приходит никому в голову, в том числе например вам. :)
no subject
no subject
Способов, альтернативных приведенному в пример, я сходу расскажу штук 5, если что :-)
no subject
Т.е., по факту, выкинуть вообще таблицы вида (в данном случае) b_iblock_property, b_iblock_element_property, не стесняться просто править таблицы для получения нужных полей в соответствии с необходимостью портала. Пользователь добавляет свойство к элементу? ОК, вломить ALTER TABLE базы и всё. Удаляет - убрать. Все БД поддерживают сотни полей на таблицу. Часто даже тысячи. Можно еще делать более эффективные индексы потом (или не делать, что тоже важно). И так далее.
Ну реально же ну какую базу не возьми, это будет в несколько раз лучше работать, чем вот эти классические словарики. Я этого не видел попросту ни разу. И это типично на мой взгляд тот самый случай. Это не то что денормализация там и т.д., это скорее термины к дизайну базы. Это просто использование возможностей БД по назначению и отказ от странной практики что схема БД это типа всё, лучше убъемся об постоянные JOIN-ы табличек из двух полей, чем её менять.
А так-то, конечно, способов оптимизации и без этого решения много. Хотя в mysql навскидку ни одного нормального всё равно не приходит в голову.
no subject
А MySQL не поддерживает XML как тип данных? В PostgreSQL помойку можно запихнуть в XML, а плоскую помойку - в HStore...
no subject
no subject
я не совсем понял вопрос.
тебе не понравилось количество upper? создай вьюху.
тебе не понравилось использование inner join вместо "WHERE бла.бла=бла-бла.бла" и "IN"? ну у них так написан компилятор.
тебе не понравилось вообще счастье с INNER JOIN и требованием иметь справочник для любого повторяющегося поля? создай вьюху.
Gor
P.S. вот чего я вам до сих пор простить не могу - так это желания писать на одном языке, на одной ОС (хуже того - для одного конкретного дистрибутива), но при этом не использовать и сотой доли возможностей использованной БД. хотя я тоже видел бизнес-план Акопянца - и переходить на MSSQL было бы очень печально.
no subject
А какие возможности базы 10-летней давности мы не использовали на уровне программирования? Мне сходу приходит только PRIOR/CONNECT BY, но он работает только с деревьями, а в cmw графы сложнее.
Если что, напоминаю, что тогда в Oracle не было, например, поддержки ANSI-синтаксиса для LEFT JOIN...
no subject
Gor
no subject
no subject
Gor
no subject
no subject
показывалась (на тот момент) только на IE.
Gor
P.S. я ведь не понял и не понимаю до сих пор - зачем она была кросс-базная. все остальное нет - а она да. это принесло кому-то счастье?
no subject
Претензии к показу - извини, это не к нам. В крайнем случае к Оле, но и то вряд ли...
no subject
Gor
no subject
no subject
Gor
no subject
no subject
no subject
а для запросов есть вьюхи.
и денормализовать ее стоит только после того, как все остальное не помогло. и то, скорее всего и денормализация в этом случае не поможет.
Gor
no subject
no subject
Сюрприз был пока только один: ругань на русские символы в комментарияхменя удивила несказанно...
no subject
В Python3 всё в utf-8, включая идентификаторы.