И что, яработал с гораздо большими базами. Более того firebird позволяет из одной базы подключаться к другой и клеить запросы... Все очень быстро работает.
одно с другим левым соединением связывалось и всё. --- Добавлено --- @voral быстро насколько микротайм замерял? --- Добавлено --- или так на глаз определяешь? --- Добавлено --- Я просто тогда по совету игоря поставил себе на серв мониторинг загрузки ядра и отслеживал в какой момент была просадка. --- Добавлено --- В общем короче на мой взгляд join зло. PS. Вообще пора на NOSQL перелазить
Ну я не знаю деталей твоего того случая. Спорить сложно... Я просто 13 лет работал достаточно плотно с большими базами данных. У меня такой опыт. JOIN нужен, отказываться глупо. Но, действительно, надо понимать когда он нужен, а когда можно обойтись.
у меня есть вообще идея попробовать данные хранить в отдельных json ... Прямо конкретно по директориям. Даже хочу попробовать. Но пока что ещё руки не дошли такую библу написать. --- Добавлено --- Да он нужен всему своё место я не сопрю. Но в частности в вебе оч мало заморочек где нужен он.
и всё таки с джоин плохие воспоминания у меня. Если не будет другово вариант и джоин будет лучше я его конечно использую, но на данный момент везде хватает простых запросов. --- Добавлено --- Ды мы вроде и не разгонялись так обсуждаем Вроде всё цивильно. --- Добавлено --- а что во втором запросе нельзя будет их приложить?
--- Добавлено --- А че ее писать мемкеш и json_* Ну, а если серьезно, опять же каждому инструменту свое применение. MySQL хорош для веба в принципе, NoSQL пихать везде и для всего тоже не серьезно. В Json хранить тоже можно, тут просто надо понимать, что СУБД не просто хранилище данных, в итоге то все равно данные в определенном формате в файл записываются. А ведь надо еще предусмотреть быструю выборку, одновременную работу с одними данными и т.д и т.п... Кроме того забирая функции с СУБД в приложение ухудшается возможность масштабирвования. ведь вы уже не можете отделить свое хранилище на другой сервер.... (ну или опять это будет работать через апач)
@askanim, пожалуйста, многоязычный сайт, соответственно, для упрощения, одна таблица - это product, в ней id, price, другая - product_name, в ней product_id, language_id, name Хочу получить первые 20 товаров, при сортировке по name на языке с id 2. Я это делаю так Код (Text): select * from product join product_name on (id=product_id and language_id=2) order by product.name limit 20 Давай твой вариант без join-а
Считаю что пока не увели идею, тебе нужно не останавливаться и немедленно реализовать MongoDB на php с хранением записей в разных каталогах фс.
@mkramer, а еще захочется разные типы цен (т.е. появляется таблица цен), и отобрать "сценой для оптовиков от 50 до 100руб) --- Добавлено --- Думаешь это будет работать так же быстро как "обычное" подключение к "обычной СУБД"?
не знаю --- Добавлено --- @voral надо пробовать. Но вообще как сказали выше О ней хорошие отзывы да и стата работы намного быстрее других бд. Только я не знал что она на json --- Добавлено --- Ладно согласен тут join Но я не понимаю зачем для этого создавать две таблицы --- Добавлено --- @mkramer хотя как я и говорил всё зависит от задачи: --- Добавлено --- Но я не люблю Join всё таки я стараюсь обходить их стороной и придумывать в бд архитектуру так чтобы этого можно было по максимуму избежать --- Добавлено --- Но вот сейчас у меня есть двиг и есть фильтр, а джоином там и не пахнет там просто WHERE на одну таблицу а чтобы по категории их соединить я сначала выбираю категории присущие данным товарам а потом по where parent_id in --- Добавлено --- и вообще чем меньше таблиц тем лучше
@mkramer я либо бы предпочёл тогда делать отдельно таблицу под другой язык. Или вообще другую бд под другой язык. Ты представляешь на сколько предётся разбивать данные? А не проще тогда ещё под это держать текстовые данные в json с пометкой в ключах en,ru там и т.д
Ну если БД поддерживает, то JSON-поля тоже вариант. Но отдельная таблица гибче. Держать json где-то отдельно в не БД - вот это точно не вариант, как ты будешь его использовать в выборках?
Как вариант хранить в базе имя файла Но это наверное бред. Хотя попробовать чисто ради эксперимента можно. Но я это и не имел ввиду я имел ввиду вот это Json можно хранить и в текстовом поле --- Добавлено --- а вообще вроде и мускуль и постгря их поддерживает --- Добавлено --- согласен а лучше отдельный mysql сервер лупануть --- Добавлено --- на другой язык. --- Добавлено --- чисто копия тока на другом языке... Тут как бы и нагрузка на бд будет меньше и вообще оптимальность как ни посмотри. Да денежно затратнее. Ну а чё делать) --- Добавлено --- Хотя надо у @igordata спросить. А как ты у себя в базе локализацию держишь на двух разных языках в сети?
Тебя сильно удивит наличие поддержки индексов на Json-типы полей и функциональных индексов в реляционных СУБД?
@Zuldek я знаю что так можно. Но мускуль раньше не жрал json он же ток там 5 и с какой то там его есть начал --- Добавлено --- @Zuldek а ща он его жрёт. Ну про поля в которых находится другой язык контента... Не думаю что на эти поля нужны индексы и поиск будет реализован по ним. Ибо поиск и сортировка у нас как правило либо на цифры либо на инглишь наименования. Или сортируете по русскому тоже? --- Добавлено --- вы же не посылаете имена параметров в русиче) --- Добавлено --- скажем в постах. ) И переменные по русски не пишете) --- Добавлено --- к слову вообще не удивил
Кстати нашёл отличную статью про хайлоад. https://habrahabr.ru/company/oleg-bunin/blog/329222/ На счёт джоинов кстати говорят что это хорошо там. Но я думаю что это точно не хорошо когда можно обойтись без них и делают их) --- Добавлено --- не понял
Нифига себе. У меня совершенно одинаковый товар, но названия на русском и английском. И я буду ради этого два отдельных сервера поднимать? Ну уж нет
Я бы поднял разделил нагрузку по локализации. --- Добавлено --- Я бы наверно если взялся за нагржуенный проект то наверное взял бы микросервисную архитектуру
Как написано в той статье на хабре, на которую ты ссылку кинул, надо сначала достичь такой нагрузки, чтоб это стало проблемой, а потом уже решать эту проблему. Контакт сначала жил себе на MySQL, а потом они написали свою БД, когда MySQL перестало хватать.