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

[beldmit]

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

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

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

Comments

[http://users.livejournal.com/_ltt_/]

Самое весёлое в этом конкретном треде, на который ты дал ссылку — даже не поведение "Битрикса" (всем известно, что это за зверь), и не то, что есть нормальный вариант избавиться от этого кошмара. Самое весёлое — это первый же ответ на пост: "Потому что хостер кривой. Меняйте на адекватного".

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

[beldmit.livejournal.com]

В наше время биотехнологий и клонирования - не гарантия. К тому же, вирус распространяет ментальный :-)

[tarkhil.livejournal.com]

"Сервер на запрос отвечает - мужик, ты охуел. Что делать?"

[dimas.livejournal.com]

хе-х, ты попроси Тома, он тебе много про битрикс расскажет кмк ...

знал бы ты, сколько я таких патчиков в своё время нашел-сделал ... типа, блин, внутреннего запроса с теми же именами полей, вставленный кем-то из джуниоров по критику или еще какого украшательства, после чего регулярный процесс перестал в 20% случаев работать ...

[beldmit.livejournal.com]

Не надо мне Тома :-)

Предесть патча на самом деле не в том, что он фиксит баг - это было бы не так прикольно. Просто с нуля пишется метод - и все, финита. Кайф же!

[dimas.livejournal.com]

тю, это весь ООП такой :) написали метод - заработала фича :)))

[beldmit.livejournal.com]

Ага. Вот теперь думаю, не сделать ли этот метод в родительском классе виртуальным, чтоб неповадно было впредь :-)

[city-rat.livejournal.com]

Диагноз: [наименование прикладного продукта]-программисты.

[beldmit.livejournal.com]

Ежели по первому абзацу - да нет, просто строго применили теорию: денормализовали и аккуратно построили запрос :-)

[city-rat.livejournal.com]

Ну вот именно [прикладные продукты] к подобному поведению и приучают. Т.е. есть две категории [прикладной продукт]-программистов: стихийные, которые ворочают совершенно индийский код, и обученные в институте, которые применяют теорию, порождая чудовищные решения.

[dmih.livejournal.com]

Вообще, "в чистом SQL-e", куда чуть ли не в стандарт входят такие слова как ALTER TABLE, такие задачи я еще лет 10 назад успешно и без проблем решал просто динамическим созданием нужных таблиц под поля. Увидел в свою очередь у предыдущего умного человека, и так далее.
Для меня до сих пор загадка, почему такой простой, прямолинейный, качественный, эффективный способ не приходит никому в голову, в том числе например вам. :)

[dmih.livejournal.com]

(сейчас конечно придут и вдесятером объяснят, почему, в пользу решений см. по ссылке, видимо ;)

[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]

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

[ask-ripe.livejournal.com]

Дима,
я не совсем понял вопрос.
тебе не понравилось количество upper? создай вьюху.
тебе не понравилось использование inner join вместо "WHERE бла.бла=бла-бла.бла" и "IN"? ну у них так написан компилятор.
тебе не понравилось вообще счастье с INNER JOIN и требованием иметь справочник для любого повторяющегося поля? создай вьюху.

Gor
P.S. вот чего я вам до сих пор простить не могу - так это желания писать на одном языке, на одной ОС (хуже того - для одного конкретного дистрибутива), но при этом не использовать и сотой доли возможностей использованной БД. хотя я тоже видел бизнес-план Акопянца - и переходить на MSSQL было бы очень печально.

[beldmit.livejournal.com]

Саша, в приведенном примере гипертрофированный вариант коммунивера получился :-)

А какие возможности базы 10-летней давности мы не использовали на уровне программирования? Мне сходу приходит только PRIOR/CONNECT BY, но он работает только с деревьями, а в cmw графы сложнее.

Если что, напоминаю, что тогда в Oracle не было, например, поддержки ANSI-синтаксиса для LEFT JOIN...

[ask-ripe.livejournal.com]

вы использовали Oracle просто как хранилище данных. написав бизнес-логику на perl.
Gor

[beldmit.livejournal.com]

Ты считаешь, что бизнес-логику надо было в триггера тащить?

[ask-ripe.livejournal.com]

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

Gor

[beldmit.livejournal.com]

Тьфу на тебя. Так не привязывались к Oracle, наоборот - делали кросс-базную хрень. Если покопаешься, там еще следы от Informix-а есть...

[ask-ripe.livejournal.com]

угу. и эта кросс-базная хрень работала на perl 5.6 apache 1.3 и debian 3.0 (уже в 3.1 ее пришлось чинить, чтобы она начала работать).

показывалась (на тот момент) только на IE.

Gor

P.S. я ведь не понял и не понимаю до сих пор - зачем она была кросс-базная. все остальное нет - а она да. это принесло кому-то счастье?

[beldmit.livejournal.com]

Ага. Куклину :-)
Претензии к показу - извини, это не к нам. В крайнем случае к Оле, но и то вряд ли...

[ask-ripe.livejournal.com]

ты хотел сказать interbase?

Gor

[beldmit.livejournal.com]

Да, ты прав.

[ask-ripe.livejournal.com]

это где не было left join? или ты именно упорствуешь в слове ANSI?

Gor

[beldmit.livejournal.com]

Именно в слове ANSI.

[beldmit.livejournal.com]

Мне не понравилось именно требование на справочник для любого повторяющегося поля, да. И строго нормализованная до маразма база.

[ask-ripe.livejournal.com]

и хорошо - нормализованная до безобразия база - это правильно.
а для запросов есть вьюхи.

и денормализовать ее стоит только после того, как все остальное не помогло. и то, скорее всего и денормализация в этом случае не поможет.
Gor

[phd_ru]

Будут проблемы - спрашивай. У себя пиши, или в BUG-лист, или в ru_python, или личной почтой...

[beldmit.livejournal.com]

Спасибо! На уровне циклов for проблем нет, а алгоритмы там не сложнее. Когда хоть какой интерфейс начну делать - появятся.

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

[phd_ru]

В Python2 код (включая литералы и комментарии) в кодировке ascii; для смены кодировки требуется директива (псевдокомментарий) coding.

В Python3 всё в utf-8, включая идентификаторы.