?

Log in

No account? Create an account

rauf


Блог Алиева Рауфа

О жизни и о себе


Previous Entry Поделиться Next Entry
В догонку про QSOFT - для техногиков, у остальных будет взрываться мозг. Впрочем, он будет у всех..
rauf
Уж раз пошла такая дудка. Они на сайте пишут про связной.ру:

Реализована сложная модель данных хранения информации по товарам, стоимости и остаткам, которые зависят от региона. Для каждой товарной категории предусмотрены отдельные наборы свойств товара.

Она действительно сложная. И это не плюс. В битриксе есть такое понятие инфоблоков. Для тех, кто не знает, это такая виртуальная таблица, работа с которой осуществляется не через SQL, а посредством API Битрикса. Подход, впрочем, не самый плохой — ORM есть во многих фреймворках. Понятно, что такая прослойка в форме API позволяет делать базовые вещи, но как только дело доходит до сложных выборок, API уже не помогает. Так вот, в базе Связной.ру несколько сот рубрик, несколько десятков тысяч товаров, которые хранятся в информационных блоках вместе со всякой мелкой шнягой. Это еще полбеды. Но вот какой злой ум придумал хранить цены там же, это нужно спросить у кусофта. Цен там много — для каждого региона и товара своя цена, в итоге выходит около полусотни тысяч записей. Да, и все это еще с контролем версий — на многие элементы велась история изменений. В итоге у нас и цены, и товары, и категории лежат в одной физической таблице на несколько сот тысяч записей. Теперь представим, что из себя будет представлять сложный запрос, отображающий список товаров с ценами из выбранных разделов — он джойнит эту огромную таблицу несколько раз.

Потом эта система с инфоблоками рушит мозг программистам и делает из них недопрограммистов, если они вовремя не хватаются за голову и не ставят ее на место. В битриксе нормальное дело не только хранить флаги и числа в VARCHAR(255), но и хранить данные разных типов в одной колонке таблицы. Специально, чтобы никакие индексы человеческие по этому построить было нельзя. Так вот, когда дело доходит до создания специальных таблиц, битриксовые программисты кусофта не долго думая создают такие же кривые структуры данных.

То, что картинки при необходимости масштабируются эксплорером — это ерунда. Ведь заказчик не заметит.

То, что типовая страница собирается 4-5 секунд, тоже нормально. Там же всего от нескольких сотен до тысячи запросов. Как бороться? просто увеличиваем кэш. Да, с кэшем запросов всего 50. Тормозит? Отключим статистику. А, так 1000 запросов из-за статистики?..

Сегодня прособеседовал двух программистов. С сожалением вижу, что люди хотят больше денег, а умеют только формы автоматизировать. Ну и простые выборки из базы данных в HTML облачать. Некоторые добились чуть большего — освоили JQuery. А проектировать умеют единицы. Думать умеют единицы. Когда даешь задачу на придумывание подхода к нестандартной задаче — все, стоп, этого в библиотеках готовых нет, это сделать нельзя.

Мне нужно обработать базу в несколько сот тысяч записей. Надо нормализовать и по ней сделать некоторую аналитику, причем нужно вырабатывать гипотезы, проверять, корректировать курс, дорабатывать скрипты, смотреть на результаты, проверять, ставить новые гипотезы, по ходу выдавать предложения, влияющие на продажи. Нужно уметь делать сложные запросы быстро, направлять результат на тут же написанный скрипт-обработчик текстовой информации, позволяющий тут же сделать выводы и скорректировать работу. Нужен исследователь-программист. Присылайте мне таких людей, нужны очень, а?


  • 1
Это уже лучше. Я даже почти всё понял))

Это еще выборка из программистов, откликаются-то все больше "год в веб-студии, 50 выполненных проектов".

а я думала, этим только рынок фриланса болеет. :)

но это ладно. больше всего доставляют кадры, которые освоили JQuery, в резюме пишут "я знаю кунфуаякс" (невольно начинаю уважать, т.к. самой все лень да некогда)... но не владеют базовыми навыками алгоритмизации. составить вложенный цикл - неподъемная задача, если без шаблонов-библиотек и туториалов.

вебдваноль, чо. индустанизация всей страны.

ORM

(Anonymous)
ORM, кстати, и создан для отображения объектов в таблицы, чтобы избежать создания огромного списка "имя-значение", а у них как раз наоборот, такрй список - эмуляция базы данных в базе данных, только индексы не эмулируются:)

Да, да... ORM создан для отображение (только наоборот) таблиц БД в объекты. Однако ORM битрикса разработчики попытались сделать слишком универсальным, за что поплатились производительностью как самой СУБД, так и клиентского кода. На моем счету реализации подобные инфо-блокам - обе похоронены, ибо приходится в итоге нормализовать ради производительности.

Чем плохи инфо-блоки битрикса.
1. Нечитабельность данных БД. Чтобы тупо просмотреть данные надо писать код, иначе не разберешься, можно конечно обойтись километровым запросом со switch/case, однако на большом кол-ве данных это полюбому fullscan таблицы и неоднократный.
2.Невозможность сделать прямые выборки - фильтрация производится в клиентском коде.
3.Низкая производительность.

С чем столкнулись: при синхронизации с другим проектом придется либо воссоздавать такую же архитектуру БД, либо дублировать и денормализовать данные. Ни первый, ни второй варианты ни есть ГУТ.

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

Однако!! При этом у Битрикса етсть право на жизнь, ибо такая(хоть и тормозная) структура БД позволяет каждой секретутке перегибать структура данных самым невообразимым образом. Соответсвенно при крутой смене структуры данных (структура БД остается неизменной) программист не требуется.


Обычные ORM абстрагируются от СУБД - Битрикс пошли дальше - абстрагировали структуру БД.

Для обмена информацией вообще говоря существует XML...

Таблица на несколько сот тысяч записей? И чо, проблема? Пять миллионов -- и шуршит-летает. Возьмите сервак нормальный.

Нет, это вообще не проблема. Проблема в архитектуре, детали лень писать. Ну как сказать... например, можно хранить дробные числа в строковых полях, можно - по-нормальному.

Да нет там проблемы с момента, когда они инфоблоки плюс сделали. То, что раньше все, что ни попадя пихалось в свойства и жило в одной таблице, да, было гиморно.

Но уже пара лет как сделаны инфоблоки плюс, где это выносится в отдельные таблицы и рисуй себе индексы какие хочешь.

Да и концепцию "масса зависимых свойств, зависящих от записи" на SQL в принципе не коряво сделать нельзя (на мой вкус), можно только сделать чтобы костыли были чуть попрямее.

Другое дело, что в "Связном" надо было нечто самописное ваять, может быть на довольно-таки низкоуровневом фреймворке, но все же специфичное, поскольку задача нестандартна изначально.

(Deleted comment)
да, мы новый софт разрабатываем уже на doctrine/symfony
совсем без абстракции нельзя, слишком сложная система

(Deleted comment)
1. например, поэтому

2. Необычного ничего. Например, сейчас 400 таблиц. Отладка с ORM проще на порядок.

(Deleted comment)
Ну да, придется. Ну можешь считать, выбор фреймворка при столь незначительных различиях — вопрос религии))

Насчет нагруженности — БД масштабируются. MySQL в этом вопросе не бриллиант, конечно, но — масштабирование работает.

понимая все недостатки инфоблоков, хочу вас спросить об альтернативе для данного их "плюса":

через инфоблок очень удобно вывести в админке в списке все названия столбцов сущности и их значения

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

придется по-любому создавать дополнительную таблицу с описанием полей сущности - другого варианта я не вижу, может быть вы подскажете ?

Обычно под задачу пишут ПО, а не наоборот)
В данном случае возникла проблема, которая не является частью требований
Это как полезное свойство, которое никто не просит, но раз есть - попробуем использовать
во-вторых, удобный вывод - это для программеров или юзеров? В обоих случаях нужно просто сделать хорошую abstract layer для БД и единый интерфейс для юзера. Битрикс это дает out-of-the-box, что просто экономит время

отсюда вывод - использовать битрикс целесообразно в случаях, когда мало времени и денег. У нас это 90% проектов, но все минусы этого нужно понимать, конечно.

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

высылайте резюме мне на мыло
я чуть позже отзвонюсь

  • 1