Russian TYPO3 community Форум больше не используется. Присоединяйтесь к каналу #community-ru в Slack for TYPO3 community  

Вернуться   Russian TYPO3 community > Выбор CMS, позиционирование TYPO3, бизнес веб-разработки > Вопросы выбора CMS

Ответ
 
Опции темы Опции просмотра
Старый 24.03.2011, 18:20   #1
bobadd
Новенький
 
Регистрация: 24.03.2011
Сообщений: 3
По умолчанию

Добрый день,

Прочитал с интересом. Сам уже 3-й год разрабатываю исключительно на Битриксе. Появилось несколько вопросов к автору. Например: что натолкнуло вас на мысль, что продуктовые цены хранятся в той же таблице, что и элемент?
Элементы, его свойсва и его цены хранятся в разных таблицах (b_iblock_element, b_iblock_property и b_catalog_price соответственно). Поэтому если у вас несколько сот тысяч продуктов - живите с миром =) Необязательно делать JOIN-выборку на 100к продуктов (если конечно у вас на одной странице не выводятся все 100к продуктов разом... что само по себе абсурдно).
В Битриксе можно сделать выборку всего и сразу... одним большим запросом через API. Но
обычно делается выборка продуктов, лимитированная паджинацией, далее для продуктов выбираются отдельно свойства, отдельно цены. Всё варьируется от сложившихся обстоятельств. Другое дело как это обустроили QSOFT. Надеюсь, что они стали снимать штаны через голову... Хотя некоторые вещи, описаные выше поистине будоражат воображение =)
4-5с на страницу - это конечно полнейшее кощунство. Но если писать с умом, грамотно использовать кэширование, расставлять индексы, и, что наиболее важно, корректно сконфигурировать серверную тачку, этого можно избежать.
Также можно рассмотреть аспекты веб-оптимизации из ряда спрайтирования; gzip контента; использрование flush(); конфигурирование CDN и т.д.
Есть сайты продуктовыми линейками подобных размеров, есть сайты с посещаемостью в 100к уников в день (на базе битрикса). И ничего. Стоят не падают и время отдачи страницы не превышает секунду, более того зачастую укладываются в полсекунды.
Поэтому в данном контексте я хочу встать на защиту Битрикса. Не стоит сразу вставать в штыки, если систему знаете достаточно поверхностно. Есть конечно свои минусы, но в целом система весьма достойна. Разумеется, если грамотно использовать её потенциалы, и обходить тонкие места.
bobadd вне форума   Ответить с цитированием
Старый 25.03.2011, 23:54   #2
Valery Romanchev
Administrator
 
Аватар для Valery Romanchev
 
Регистрация: 23.08.2003
Адрес: Moscow, Russia
Сообщений: 1,926
Отправить сообщение для Valery Romanchev с помощью Skype™
По умолчанию

Цитата:
Сообщение от bobadd Посмотреть сообщение
Добрый день,

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

Цитата:
Сообщение от bobadd Посмотреть сообщение
Элементы, его свойсва и его цены хранятся в разных таблицах (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 Битрикс.
__________________
Веб-студия ТТЛАБ
www.ttlab.ru
Valery Romanchev вне форума   Ответить с цитированием
Старый 26.03.2011, 02:36   #3
bobadd
Новенький
 
Регистрация: 24.03.2011
Сообщений: 3
По умолчанию

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

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


А насчет цитаты про СМИ, не очень понял, люди всё-таки остались на битриксе и подпилили ему API? Или отказались от него полностью?
bobadd вне форума   Ответить с цитированием
Старый 26.03.2011, 13:13   #4
Valery Romanchev
Administrator
 
Аватар для Valery Romanchev
 
Регистрация: 23.08.2003
Адрес: Moscow, Russia
Сообщений: 1,926
Отправить сообщение для Valery Romanchev с помощью Skype™
По умолчанию

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

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

Цитата:
А насчет цитаты про СМИ, не очень понял, люди всё-таки остались на битриксе и подпилили ему API? Или отказались от него полностью?
Сформулировано, по-моему, четко. Вы троль чтоли?
__________________
Веб-студия ТТЛАБ
www.ttlab.ru
Valery Romanchev вне форума   Ответить с цитированием
Старый 26.03.2011, 18:22   #5
bobadd
Новенький
 
Регистрация: 24.03.2011
Сообщений: 3
По умолчанию

Я не знаю что подразумевается под словом "троль"

Цитата:
полностью отказались в процессе разработки от использования Битрикс API для доступа к контенту в базе данных. были написаны свои модули, генерирующие прямые sql-запросы
Я переспросил потому, что можно написать свой модуль для Битрикс который будет делать прямые запросы к БД.
bobadd вне форума   Ответить с цитированием
Старый 29.03.2011, 22:56   #6
jettero
Senior Member
 
Регистрация: 24.06.2006
Сообщений: 143
По умолчанию

Цитата:
Сообщение от Valery Romanchev Посмотреть сообщение
Одно дело, когда структура данных как в учебниках, и совсем другое дело, когда как здесь http://2push.net/sites/default/files/bitrix_bd.jpg
не в качестве защиты битрикса..
но про такие структуры данных в учебниках тоже пишут http://en.wikipedia.org/wiki/Entity-...te-value_model
кстати в экстеншене commerce тоже такая модель данных
jettero вне форума   Ответить с цитированием
Старый 30.03.2011, 20:14   #7
Valery Romanchev
Administrator
 
Аватар для Valery Romanchev
 
Регистрация: 23.08.2003
Адрес: Moscow, Russia
Сообщений: 1,926
Отправить сообщение для Valery Romanchev с помощью Skype™
По умолчанию

Цитата:
Сообщение от jettero Посмотреть сообщение
не в качестве защиты битрикса..
но про такие структуры данных в учебниках тоже пишут http://en.wikipedia.org/wiki/Entity-...te-value_model
Врядли есть хоть один учебник, который порекомендует делать интернет-магазин без "нормальной человеческой" таблицы products :-)
Цитата:
Сообщение от jettero Посмотреть сообщение
кстати в экстеншене commerce тоже такая модель данных
В commerce как раз есть нормальная таблица товаров (tx_commerce_products)
__________________
Веб-студия ТТЛАБ
www.ttlab.ru

Последний раз редактировалось Valery Romanchev; 30.03.2011 в 20:41
Valery Romanchev вне форума   Ответить с цитированием
Старый 30.03.2011, 22:46   #8
takitak
Новенький
 
Регистрация: 03.02.2011
Сообщений: 25
По умолчанию

Не знаю насчет учебника, а case study с крупным магазином без такой таблицы я видел. Продукты лежат в NoSQL хранилище. В SQL - только заказы. Уж как они разруливали с со своим учетом - про то не написано. Собссно, что битриксовская модель, что TV - попытка хранить в БД то, для чего она плохо подходит.
takitak вне форума   Ответить с цитированием
Старый 31.03.2011, 13:22   #9
jettero
Senior Member
 
Регистрация: 24.06.2006
Сообщений: 143
По умолчанию

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

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

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

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

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

Последний раз редактировалось jettero; 31.03.2011 в 13:36
jettero вне форума   Ответить с цитированием
Ответ


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB code is Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Часовой пояс GMT +4, время: 08:27.


Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot

Хостинг и техническая поддержка: TYPO3 Лаборатория