PDA

Просмотр полной версии : Отзыв заказчика о "лучшем" проекте 2010, разработанным QSOFT (лидером продаж Битрикс)


Valery Romanchev
16.04.2010, 11:39
Речь идет о сайте "Связной"
Сами отзывы
http://rauf.livejournal.com/358741.html
http://rauf.livejournal.com/359109.html

обсуждение появилось здесь
http://community.livejournal.com/ru_cms/403730.html


Связной и QSOFT
не сдержался и откомментировал работу QSOFT для нас (http://mtoko.livejournal.com/16632.html?view=96504#t96504). Правда, наболело) Недавно, например, столкнулись с тем, что у нас нельзя зарегистрироваться на сайте с паролем "123456". Причем именно с таким. Вот 234567 или 1234567 — можно. А «стрит» с единички не катит.

Оказалось, там прям такая проверка в коде стоит: «если пароль 123456, то отказать». Вот думаю, может быть, в ТЗ была формулировка: «должна быть предусмотрена проверка на простые пароли (123456)». Вот, смотрите, проверка работает! Не знаю, как оно там было, меня тогда здесь не было.

UPDATE: потерли комментарий мой. Не знаю, что в нем такого плохого
http://img-fotki.yandex.ru/get/4009/raufal.40/0_2176c_42425d5c_XL
Вежливо же написал:

Друзья,

Это, конечно, очень приятно, что Связной.ру поставили на первое место. Но было бы не лишним узнать мнение Связного о том, как QSOFT выполнил свою работу. Я руковожу разработкой Связной.ру, поэтому совершенно ответственно могу заявить о полном непрофессионализме разработчиков Связной.ру со стороны QSOFT, о массе кривых решений, которые, будучи наложенными на недостатки Bitrix, сделали необходимым полную переработку половины сайта. Ощущение такое, что проект выполняли студенты медицинского техникума российской глубинки, вооруженные справочником по PHP & MySQL. Если нужны факты — я могу сразу запостить сюда с десяток примеров. Как кода, так и структуры БД. Это самый позорный проект из всех, которые когда-то выпускал QSOFT, если начать смотреть в то, что получилось. Уж простите меня, пожалуйста.


В догонку про QSOFT - для техногиков, у остальных будет взрываться мозг. Впрочем, он будет у всех..
Уж раз пошла такая дудка. Они на сайте пишут про связной.ру:
Реализована сложная модель данных хранения информации по товарам, стоимости и остаткам, которые зависят от региона. Для каждой товарной категории предусмотрены отдельные наборы свойств товара.
Она действительно сложная. И это не плюс. В битриксе есть такое понятие инфоблоков. Для тех, кто не знает, это такая виртуальная таблица, работа с которой осуществляется не через SQL, а посредством API Битрикса. Подход, впрочем, не самый плохой — ORM (http://ru.wikipedia.org/wiki/ORM) есть во многих фреймворках. Понятно, что такая прослойка в форме API позволяет делать базовые вещи, но как только дело доходит до сложных выборок, API уже не помогает. Так вот, в базе Связной.ру несколько сот рубрик, несколько десятков тысяч товаров, которые хранятся в информационных блоках вместе со всякой мелкой шнягой. Это еще полбеды. Но вот какой злой ум придумал хранить цены там же, это нужно спросить у кусофта. Цен там много — для каждого региона и товара своя цена, в итоге выходит около полусотни тысяч записей. Да, и все это еще с контролем версий — на многие элементы велась история изменений. В итоге у нас и цены, и товары, и категории лежат в одной физической таблице на несколько сот тысяч записей. Теперь представим, что из себя будет представлять сложный запрос, отображающий список товаров с ценами из выбранных разделов — он джойнит эту огромную таблицу несколько раз.

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

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

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

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

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

Nobody
21.04.2010, 19:02
Спасибо за материал :) Интересно читать было. Битрикс – та ещё поделка, а кривость кусофта поражает :)

Точный рецепт сочинить сложно, не зная полной картины. Прикинуть можно. Для исправления ситуации я бы вычленил типы данных и выделил бы их в отдельные таблицы с правильными типами полей. Так эффективнее. В каждой таблице сделал бы композитный уникальный ключ по версии + номеру записи (не тоже самое, что autoincrement field). Поверх этого написал бы общий API, который может обращаться к данным и выдавать их с использованием магических методов. Для особых случаев сделал бы подклассы для объектов данных... Как–то так на первый взгляд. Было бы намного проще и быстрее, чем гигантские джоины делать.

bobadd
24.03.2011, 18:20
Добрый день,

Прочитал с интересом. Сам уже 3-й год разрабатываю исключительно на Битриксе. Появилось несколько вопросов к автору. Например: что натолкнуло вас на мысль, что продуктовые цены хранятся в той же таблице, что и элемент?
Элементы, его свойсва и его цены хранятся в разных таблицах (b_iblock_element, b_iblock_property и b_catalog_price соответственно). Поэтому если у вас несколько сот тысяч продуктов - живите с миром =) Необязательно делать JOIN-выборку на 100к продуктов (если конечно у вас на одной странице не выводятся все 100к продуктов разом... что само по себе абсурдно).
В Битриксе можно сделать выборку всего и сразу... одним большим запросом через API. Но
обычно делается выборка продуктов, лимитированная паджинацией, далее для продуктов выбираются отдельно свойства, отдельно цены. Всё варьируется от сложившихся обстоятельств. Другое дело как это обустроили QSOFT. Надеюсь, что они стали снимать штаны через голову... Хотя некоторые вещи, описаные выше поистине будоражат воображение =)
4-5с на страницу - это конечно полнейшее кощунство. Но если писать с умом, грамотно использовать кэширование, расставлять индексы, и, что наиболее важно, корректно сконфигурировать серверную тачку, этого можно избежать.
Также можно рассмотреть аспекты веб-оптимизации из ряда спрайтирования; gzip контента; использрование flush(); конфигурирование CDN и т.д.
Есть сайты продуктовыми линейками подобных размеров, есть сайты с посещаемостью в 100к уников в день (на базе битрикса). И ничего. Стоят не падают и время отдачи страницы не превышает секунду, более того зачастую укладываются в полсекунды.
Поэтому в данном контексте я хочу встать на защиту Битрикса. Не стоит сразу вставать в штыки, если систему знаете достаточно поверхностно. Есть конечно свои минусы, но в целом система весьма достойна. Разумеется, если грамотно использовать её потенциалы, и обходить тонкие места.

Valery Romanchev
25.03.2011, 23:54
Добрый день,

Прочитал с интересом. Сам уже 3-й год разрабатываю исключительно на Битриксе. Появилось несколько вопросов к автору. Например: что натолкнуло вас на мысль, что продуктовые цены хранятся в той же таблице, что и элемент?
Вопросы автору нужно, конечно, задавать в блоге автора. Здесь же приведена цитата.


Элементы, его свойсва и его цены хранятся в разных таблицах (b_iblock_element, b_iblock_property и b_catalog_price соответственно). Поэтому если у вас несколько сот тысяч продуктов - живите с миром =)
Я бы предпочел в реальной сложной учетной системе с 100 - 200 таблицами иметь дело с обычной "человеческой" структурой данных, с таблицами имеющими понятные названия типа products, categories и т. п.

Это дает лишний "контур" для получения отчетов и работы с системой.
Если надо что-то сделать или получить отчет, то пишешь SQL запрос. Т.е. используешь реляционную СУБД таким образом, как их и предполагалось использовать когда-то в древности :-)

Подронее на эту тему можно посмотреть здесь
http://job-interview.ru/articles/post/234
http://2push.net/node/240
Цитата:
В заключение приведу примеры из личного опыта: два больших высоконагруженных проекта Интернет-СМИ, созданных на CMS Битрикс 9.0, полностью отказались в процессе разработки от использования Битрикс API для доступа к контенту в базе данных. были написаны свои модули, генерирующие прямые sql-запросы. причём тормоза API выявились в процессе разработки, когда переходить на другую CMS было уже нерентабельно. имея эти данные изначально, высока вероятность принятия решений ведения разработки на каком-либо фреймворке и отказ от использования CMS Битрикс.

bobadd
26.03.2011, 02:36
Насчет именования таблиц - мне кажется слегка натянуто. Когда работаешь с системой и знаком с соответствующей спецификой и терминологией - всё сразу становится понятно. Между прочим, название таблиц писал по памяти =)
b_iblock_element:
b = bitrix,
iblock = названия модуля (Информационные Блоки)
element = я думаю не стоит представлять

и так все таблицы... достаточно лаконично, на мой взгляд.


А насчет цитаты про СМИ, не очень понял, люди всё-таки остались на битриксе и подпилили ему API? Или отказались от него полностью?

Valery Romanchev
26.03.2011, 13:13
Насчет именования таблиц - мне кажется слегка натянуто. Когда работаешь с системой и знаком с соответствующей спецификой и терминологией - всё сразу становится понятно. Между прочим, название таблиц писал по памяти =)
b_iblock_element:
b = bitrix,
iblock = названия модуля (Информационные Блоки)
element = я думаю не стоит представлять

и так все таблицы... достаточно лаконично, на мой взгляд.

Дело, конечно, не в названиях, а структуре данных :-)
Одно дело, когда структура данных как в учебниках, и совсем другое дело, когда как здесь http://2push.net/sites/default/files/bitrix_bd.jpg
Те, кто админил/поддерживал учетные системы хотя бы средней сложности, поймет :-)


А насчет цитаты про СМИ, не очень понял, люди всё-таки остались на битриксе и подпилили ему API? Или отказались от него полностью?
Сформулировано, по-моему, четко. Вы троль чтоли?

bobadd
26.03.2011, 18:22
Я не знаю что подразумевается под словом "троль"

полностью отказались в процессе разработки от использования Битрикс API для доступа к контенту в базе данных. были написаны свои модули, генерирующие прямые sql-запросы

Я переспросил потому, что можно написать свой модуль для Битрикс который будет делать прямые запросы к БД.

jettero
29.03.2011, 22:56
Одно дело, когда структура данных как в учебниках, и совсем другое дело, когда как здесь http://2push.net/sites/default/files/bitrix_bd.jpg
не в качестве защиты битрикса.. :D
но про такие структуры данных в учебниках тоже пишут http://en.wikipedia.org/wiki/Entity-attribute-value_model
кстати в экстеншене commerce тоже такая модель данных

Valery Romanchev
30.03.2011, 20:14
не в качестве защиты битрикса.. :D
но про такие структуры данных в учебниках тоже пишут http://en.wikipedia.org/wiki/Entity-attribute-value_model

Врядли есть хоть один учебник, который порекомендует делать интернет-магазин без "нормальной человеческой" таблицы products :-)

кстати в экстеншене commerce тоже такая модель данных
В commerce как раз есть нормальная таблица товаров (tx_commerce_products)

takitak
30.03.2011, 22:46
Не знаю насчет учебника, а case study с крупным магазином без такой таблицы я видел. Продукты лежат в NoSQL хранилище. В SQL - только заказы. Уж как они разруливали с со своим учетом - про то не написано. Собссно, что битриксовская модель, что TV - попытка хранить в БД то, для чего она плохо подходит.

jettero
31.03.2011, 13:22
Врядли есть хоть один учебник, который порекомендует делать интернет-магазин без "нормальной человеческой" таблицы products :-)

В commerce как раз есть нормальная таблица товаров (tx_commerce_products)

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

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

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

В общем у меня эта схема вопросов не вызывает и это вполне в русле учебников. Но не сочтите это за агитацию за Битрикс ))