Что использовать для хранения данных в битриксе: HighloadBlock или ORM?
Здравствуйте! Интересует мнение битрикс-разработчиков. Для хранения данных что лучше использовать ORM в модуле битрикса или выносить в highloadblock все данные?
Например нужно хранить данные о событиях. Событие выставка проходит несколько дней - структура highloadblock приблизительно имела бы следующие пользовательские поля - Название, Дата (множественное), Цена, Город (привязка к ИД) и некоторые другие. То же самое можно сделать и в ORM класса в модуле на новом ядре битрикса, но вот как хранить множественные значения дата с возможностью выборки с упоминанием этой даты (то есть нужно быдет выбрать все события на определенный день). Плюсы хайлоад - не нужно писать дополнительный интерфейс в админке для событий и думаю с выборкой множественных значений проблем не возникнет. А вот с orm еще не до конца все понятно. Меня интересует ваше мнение - что бы вы использовали, аргументы и, возможно, я вообще неправильно нахожу применения этим инструментам от Битрикс.
вообще я не увидил причины использовать hiloadblock, ну если у вас нет мании к проектированию бд
Highload-блоки - модуль для работы с произвольными наборами данных в условиях высоких нагрузок.
У вас большой поток данных ? Настолько большой что маштабировать систему стандартным методом невозможно ?
А в скорости будет разница? Вроде и первый и второй варианты используют прямые обращения в бд. Встречный вопрос - возможно на ORM сделать множественное поле типа дата и затем делать выборку по совпадению даты getList'ом?
Смотрите внимательнопо тексту
мне кажется вы делаете какую-то хеню.
Все что вы пока описали укладывается в стандартную работу по АПИ смысла городить вообще изначально не вижу.
Добавьте в тз больше конктетики,
У вас гигантские объемы данных, вы хотите добиться производительности выше чем. и тд и тп.
смысл делать костыль как ни покрути.
В чем смысл таких издивательств ?
ShamblerR: пишу модуль с юзабельным интерфейсом, хочется найти максимально оправданное средство для хранения данных о событиях, инфоблоки отметаю, там много лишнего. ORM еще не использовал, мне нужно хранить несколько дат к одному событию, множественное свойство дата и затем по определенной дате делать выборку событий. Гигантских объемов нет. На ORM как сделать множественное свойство с датами?
Значит тебе нужно просто ползоватся битрикс, если бы мои ребята написали что-то подобноя я бы быстро их штрафанул тысяч на 5 для профилактики. не изобретайте велосипед Пользуйтесь стандартным функционалом.
Вы как понапишете "правельных модулей" без документации а нам потом их на стандартные переводить.
ShamblerR: Уважаемый, вам не кажется что вы начали изливаться желчью? Вроде я вопрос вполне конкретный задаю, если вы против горе-программистов, после которых к вам обращаются как к разработчику - то это не мои проблемы. Это во-первых. Во вторых, я модуль пишу для своих потребностей, так что перестаньте истерить. И вообще, что вы делаете на этом ресурсе? Вопросы обходите стороной, ваши сообщения веют негативом. ЗаметьТЕ, я обращался к ВАМ, а не ТЫкал :)
faragly: да не стоит так волноваться честное слово, не воспринимайте уж так все на свой счет. Но если вы думаете вы первый кто пытается написатьс вой функционал, да у меня тут народ свои хлебные крошки пишет, ибо у битрикса там "лишний код". Каждый прогер пытается написать свое и это я понимаю, вопрос в том что не оставляя ни документации ни разбираясь в движке лучше самих разрабочтиков вероятность написать что-то полезное что потом еще и можно будет нормально поддерживать стремится к нулю. фактически 99% сайтов приходящих на рефакторинг это какраз вот такие вот поделки, когда програмиист ( замечу это не говорит о том что он плохой специалист) пишет воот такой вот код. С точки зрения его поддерживания это мертвый код, стоимость поддержки и обновления егостановится заоблачный а профита с этого как правила 0.
Именно это я и говорю а не то что вы не проффесионал и не в состояние написать качественный код.
Просто он не нужен.
я вам могу дать десятки проектов с посещяемостью за 10К собраных толко на стандартных компанентах.
А данные о событиях вообще логируются стандартным штатным методом.
ShamblerR: то что я пишу - в стандартном битриксе нет 100%, я начал работать с этой системой с версии 6.0, я знаю что я не хороший прогер, но я хотя бы это признаю. То что я делаю - стандартным функционалом не сделать (можно сделать связки в инфоблоках, но компоненты однозначно писать придется и это будет убого, так я уже делал). На данный момент я написал часть модуля, пусть код не идеальный, но он делает свое дело. В данный момент я признаю что я мне многому нужно научиться и поэтому я здесь. Я не начал городить свой код на highloadblock потому что я подозреваю что это нужно делать на ORM, но я не знаю как делать множественное поле дата и потом как я буду работать с этими данными, поэтому собственно и спросил.
ShamblerR: Я тогда сделал киноафиши, было 3 инфоблока - с сеансами, с фильмами, с кинотеатрами. Каждый сеанс добавлялся на отдельной странице (как обычный элемент инфоблока добавляется, в этом первая убогость, нет множественного добавления). Ручное добавление фильма с множеством полей, копи-паст лишний геморрой. Цены на сеансы также хранились в отдельном инфоблоке, цены отличались в зависимости от кинотеатра, фильма, социльного статуса (детские, студенческие, взрослые). Это что касается убогости добавления и редактирования. Сам компонент был написан по уму как мне казалось, запросы в базу сводились к минимуму, но скорость вначале была секунда-полторы после сброса кэша, после оптимизации удалось добиться 100-150 миллисекунд. По сравнению с остальными страницами это в 5-10 раз дольше. Сейчас же сделан удобный интерфейс в админке, с ангуляром и прочими плюшками, встал вопрос как все же хранить сеансы.
вы интегрировались с ?
кинохода
рамблер кассы
афиша
или с USC или ему подобной системой ?
Количество кинозалов ?
Количество городов ?
Если можно то какя именно киносеть.
Более подробно могу помочь
Вот только на днях сдаем интеграцию с usc киноход и рамблер кассу.
ShamblerR: без интеграций на данном этапе, для городского портала. В моем городе не давали возможности для подключения к UCS, поэтому расписание высылали почтой, контент-менеджер забивал все это.
откажись от кассы, киноход лучше, касса блевотина еще та.
Вопервых апи более тупое.
во вторых там нет даже трейлеров, нет нарезки фильмов, нельзя нормально привязать фильм одновременно кнотеатрам и дате, или к дате или к театру но не к дате и к списку театров.
контент намного более убогий.
готовый киноход могу отдать, готовую рамблер кассу сейчас доделываю
скрипт по кронуобменитвается данными занимает примерно 02 секунды, плюс сама подгрузка контента. В принципе для 5-6 кинотеатров хватает. Сейчас есть еще сложность с обновлением списка фильмов на аяксе при выборе датты но это сейчас решаем.
в
ShamblerR: спасибо, было бы отлично! то есть в вашем решении сеансы как промежуточные данные не сохраняются в БД? У меня насчет контента вопрос не встал, я сделал автоматический парсинг кинопоиска, в админке выбирается постер и кадры и одним нажатием дбавляется как элемент инфоблока. А сеансы планировал привязывать к ИД фильма
автоматический прарсер не покатит основные лидеры меняю структуру всего сайта раз в несколко месяцев ( специально)
что касается расписания то нет оно не хранится лишние инфоблоки с лишним паражняком, для сео расписание не важно.
все остальное мы сохраняем естественно фильмы архивы анонсы деталки, все держем у себя.
ShamblerR: ну а как быть с городами и кинотеатрами, которые не подключены к киноходу и кассе? В Кургане например только 1 из 5 кинотеатров подключен, остальные 4 пользуются также большим спросом, но они пока не доперли до киноходов и касс. Мой город имеет 2 кинотеатра и ни один не подключен, то есть для горпортала важно иметь возможность хранить эти данные. Вы бы как хранили сеансы? Кинопоиск последний раз не раньше года назад менял структуру, весь парсинг происходит в одной функции, так раз в год можно и переписать селекторы. Можете на почту написать? faragly@mail.ru
здрасти так все просто платиш $ подключаешся сам сервис рисует твой зал места и тд. На сахалине их тоже небыло так появились же ;)
теперь что по части городов тоже все сделано, если нужно хранить сеанс то храните их штатным методом если вам прям уж так жалго раздувать базу так храните его текстовым полем с табуляторами да парсите себе наздоровье. при выводе.
В конце концов естьготовые решения расписаний типа "сайт медицины" "сайт школы" "сайт конференции"
там уже реализовано хранение расписания, дертине код.
