Сломал парням весь тред ты... . Уже почти пришли к хедупу на пыхыпе и hbase для многоязычности екомерса
Да это повод подумать об архитектуре ДБ, есть наверное способы имитировать большую нагрузку на базу Hadoop ? это зачем?
вот и битрикс зачем не спрашивал... Чисто моё мнение нужно код сразу делать нормальным. И например на мой взгляд джоинов в проекте должно на столько меньше насколько это возможно, а active record вообще не должно быть в веб проекте --- Добавлено --- и это сугубо моё личное мнение сложившееся за годы разработки в web индустрии
Да ну. Надо просто себе представлять, в какой запрос преобразуется твой AR, и тогда вполне можно пользоваться - это зачастую удобно. К примеру, вот строчка из моего проекта, получающая пользователей, у которых закончился оплаченный период Код (Text): $users = User::find()->tariffEnds(new \DateTime("-1 day"))->all(); Это же лучше смотрится, чем SQL запрос. А какой будет SQL-запрос в итоге я знаю, руками бы я его примерно также и написал --- Добавлено --- Я всегда хорошо себе представляю, что будет за запрос в итоге, и проверяю, если что.
@keren, потому что заданная ТС тема себя исчерпала. Чтобы писать хорошо ОО, надо много читать теории ОО.
Окей. Классический кейс. У тебя книги, авторы, отзывы покупателей. У каждой сущности набор своих свойств. Бизнес-задача: вывести ленту книг с их характеристиками, информацией об авторах, отзывы покупателей. Книг, отзывов и авторов много. Как будет построена структура данных и их получение конкретно для такой задачи?
Будет 4 таблицы книги, авторы, отзывы покупателей и таблица соединяющая две таблицы с двумя полями idКниги и idАвтора реализующую связь многие ко многим. А в таблице отзывов idКниги и например имя и поле сообщения. Тут всё просто до ужаса. Если мы получаем конкретную книгу то join не нужен. Обычно отзывы уже прикрепляются к каждой определённой книге когда ты проваливаешься во внутрь не посредственно товара и там выводятся отзывы так что там join не нужен связывающий три таблицы я просто сделаю в одном соединении три запроса на получение данных о книге авторах книги и для получения отзывов. Если же говорить о выводимом списке. То нужно смотреть какая будет бизнес логика. Например у книги могут быть несколько авторов, а также и авторов ещё может быть несколько книг, как будем группировать по книгам или авторам? Согласен при выводе всего списка книг и авторов к ним причетающих лучше сделать join. Но правда тут смотря какая будет бизнес логика. Ты дал мало информации дай конкретнее как группируем и скажу нужен там join или нет на мой взгляд. --- Добавлено --- @Zuldek Тут даже не так тут нужно сесть и потратить часок создать архитектуру бд, и после заняться выводом их данных согласно бизнес логики! И там уже будет видно как сделать лучше. Я не говорю что Join вообще не надо юзать я говорю желательно чтобы их было меньше, как и запросов count Это тяжёлые запросы их по возможности нужно избегать, но при этом никто не говорил что нужно х.рить свой велосипед, есть стандартные процедуры вполне оптимальные для таких случяаев. Но нужно понимать когда их использовать. Поэтому на мой взгляд запрос join он не для новичков.
внимательно смотри тз: показывается лента с книгами и отзывами к ней со списком авторов. Куда еще конкретнее:?
я бы поспорил. Мне больше по душе как выглядит сама строка запроса. Ибо достаточно знаю sql чтобы их писать. Но тут складывается не удобство при масштабировании, поэтому предпочетаю query builder.... Бала Как я не подумал. Перепишу свой query builder походу) Создам под него интерфейс, и по нему сделаю строилку. Чтобы паники не было и можно было потом если надо переключить на другой
@Zuldek Тогда здесь join и лимит на получение книг. Иначе когда в базе будет их 100+ уже будет не смешно при выводе. )
да согласен в этом случае да. Но такие случаи редки когда надо так вывести. Обычно приходится иметь дело с однотипными каталогами и там ни какие джоины не нужны --- Добавлено --- Откуда такой интерес? --- Добавлено --- @Zuldek согласен на вот глянь соседмаркет.рф правда этот сайт так и не допилился зажопили с оплатой. --- Добавлено --- 200 000 потратили и решили всё для такого сайта.
@askanim в какой веб-студии ты трудился? Иными словами, с лентой книг: join. Теперь страница книги с отзывами, авторами и книгами авторов. Для этого представления ты будешь делать по запросу к каждой таблице данных?
вышка. А он напаисан чисто на php со своей панелью управление и с прямой интеграцией 1С --- Добавлено --- да так будет быстрей --- Добавлено --- три запроса одиночных пройдут быстрее чем джоин к трём таблицам --- Добавлено --- да и выводить потом на странице будет проще. Не будет одного большого массива --- Добавлено --- 1 с авторами другой с инфой о книге и третий массив отзывов --- Добавлено --- @Zuldek и на том магазине есть join даже который в цикле собирает запрос на join самого себя. Но это на самом деле там по глупости сделано надо бы там по другому. Писал я тот сайт пару лет назад когда ток пришёл на форум --- Добавлено --- Если ты считаешь что я не прав аргументы в студию! Возможно тебе удастся меня научить, что это не верно и ты аргументировано докажешь почему это не так. --- Добавлено --- я сам себе был веб студией. Но вообще сотрудничал с разными нашими коллегами, в том числе и с форума. Даже работал в паре как - то с математиком на студии. Но инфа засекречена и доступна только определённому кругу лиц и о личной информации на общий доступ я изрекаться не собираюсь.
@Zuldek как то я разбирал 7 друпалс. Там был запрос и в нём чтоли 9 или 10 джоинов было, а то и больше. Да точно были и побольше. Вот это было забавно прямо просто очень забавно. Я был удивлён. --- Добавлено --- Мне кажется пора тему эту бить на под темы и часть уносить в профи из новичков и дебаты уже продолжать там
Там EAV модель, без пачек join-ов никак. К любой ноде (нода - любая сущность, с которой работает CMS, пост в блоге, страница, что угодно) пользователь из админки может цеплять атрибуты динамически. У самого сейчас на одном проекте такое заказали, вот приходится с этими джоинами сидеть (правда, там ещё и структура данных, разработанная другим специалистом, была как приложение к ТЗ, я бы сам, конечно, немного по-другому сделал, попробовал бы JSON-поля на максимум задействовать, может ещё и переделаю, посмотрим)
В этом кейсе правильный ответ: как раз запросить уточнений. Только не бизнес требований,а дополнительных условий по объемам данных, подходе в их хранении и масштабировании, повторных использований данных запросов, и, разумеется, СУБД о которой идет речь. Все это повлияет на оптимальный выбор. Упрощенно говоря, однозначно универсального ответа по конкретному кейсу: что лучше один запрос с объединением (денормализация данных) или 3 запроса к разным таблицам не существует.
Знаю. Ну ты помнишь когда я писал xml выгрузку с той базы. Я вроде ругался на эту структуру. )) И выложил вариант выгрузки на форум. Он где-то канает. --- Добавлено --- +1 тут нужно думать уже по обстоятельствам чего куда. И даже думаю так, если бы было что-то тяжёлое, я бы даже поинтересовался в разделе профи правильно сделал или можно лучше. --- Добавлено --- Возможно узнал бы в этом случае для себя что-то новое. Кстате о новом тема вообще чёткая получилась её бы разбить ещё на две под темы. Тут очень ценная дискуссия лежит.
В другому проекте, я чтоб избежать EAV, сделал общую таблицу (сайт позволяет пользователям размещать объявления о продаже щебня, песка, а сейчас ещё добавились бетон и асфальтобетон, а ещё перевозка всей этой хрени). Но там атрибуты каждого материала известны на этапе разработки. Вот эта таблица уже разрослась на 44 колонки, но зато join идёт только с ней, а не по пяти таблицам. И индексами, в принципе, её можно утыкать, если проблемы со скоростью будут.
@mkramer это не страшно я видел таблицу на 55 полей. С 7 000 000 строк. Вот там была адовая хрень) Ещё и индексы нельзя было в неё засунуть потому что это таблица обновлялась по башу. --- Добавлено --- Вот был адовый трындец @igordata Помнить) Как мы вместе на стриме колдовали чёрную магию чтобы её оптимизировать --- Добавлено --- Хоспади какие там тока танцы с бубном вокруг неё не были :3 --- Добавлено --- я думаю часть темы про join можно засунуть туда https://php.ru/forum/threads/join-bystree-chem-mnozhestvo-odinochnyx-zaprosov-k-bd.63437/ И переименовать название темы в join (Да или Нет) А ещё часть про ORM вынести в тот же раздел с неазванием: Active Record, data mapper или простой query builder. Что выбрать?