Ну просто там сделано все, что мне нужно. Особенно c авторизацией через соц. сети париться не хочу

посмотрел ext от 2amigo? Понравилась?

ктонить в курсе, есть вменяемый способ игнорировать ошибки при вставке записей, которые должны быть уникальными? public function addCategory(Category $category) { $exists = ThumbsCategories::find() ->where(['category_id' => $category->category_id, 'thumb_id' => $this->thumb_id]) ->exists(); if (!$exists) { $this->link('categories', $category); } } такой кастыль щас с проверкой. many-to-many связь, в связующей таблице primary key: category_id | thumb_id (уникальные все типа)

я не понял вопрос

Я тоже

Проверку на уникальность что ли надо

или надо убрать, а в бд есть. или нужен составной внешний ключ. я хз че там

Хз

Коллеги, пришла тут в голову одна схема для хранения галлерей изображений. Хочу прокунсультироваться у тех кто шарит) Допустим есть у меня туева хуча изображений, которые распределены по галереям. У этих изображений есть подписи и другая инфа еще и на разных языках. Каждое изображение я хочу хранить в БД. С примерно таким набором полей: id, path, alt, title, intro, description Но из-за мультиязычности это дело нужно разбить на три таблицы (или больше в зависимости от кол-ва языков). И вот тут меня плющит прожорливость запроса в БД в момент вызова галереи. Дернуть страницу -> join галереи -> join изображения -> join языковой версии контента и так для каждой галереи коих на странице может быть много. Если например у галереи сделать поле tpl куда записывать уже свормированный HTML код галлереи и отдавать ее всю одним полем это норм?

Коллеги, пришла тут в голову одна схема для хранения галлерей изображений. Хочу прокунсультироваться у тех кто шарит) Допустим есть у меня туева хуча изображений, которые распределены по галереям. У этих изображений есть подписи и другая инфа еще и на разных языках. Каждое изображение я хочу хранить в БД. С примерно таким набором полей: id, path, alt, title, intro, description Но из-за мультиязычности это дело нужно разбить на три таблицы (или больше в зависимости от кол-ва языков). И вот тут меня плющит прожорливость запроса в БД в момент вызова галереи. Дернуть страницу -> join галереи -> join изображения -> join языковой версии контента и так для каждой галереи коих на странице может быть много. Если например у галереи сделать поле tpl куда записывать уже свормированный HTML код галлереи и отдавать ее всю одним полем это норм?

норм! Только если верстка табличная

я не понял вопрос

карочи в связующей таблице составной праймори ключ category_id | thumb_id. Он уникальный сам по себе. Т.е. нельзя вставить две одинаковые записи. типа 10 | 15 два раза. Но иногда нужно вставить туда весь набор категорий определенной тумбы, в том числе которые уже есть. Т.е. получится что будет вставляться дубль. и тогда вылетает исключение мол такая херь не прокатит запись уже есть. Приходится сначала проверять есть ли запись, и потом уже вставлять.

Коллеги, пришла тут в голову одна схема для хранения галлерей изображений. Хочу прокунсультироваться у тех кто шарит) Допустим есть у меня туева хуча изображений, которые распределены по галереям. У этих изображений есть подписи и другая инфа еще и на разных языках. Каждое изображение я хочу хранить в БД. С примерно таким набором полей: id, path, alt, title, intro, description Но из-за мультиязычности это дело нужно разбить на три таблицы (или больше в зависимости от кол-ва языков). И вот тут меня плющит прожорливость запроса в БД в момент вызова галереи. Дернуть страницу -> join галереи -> join изображения -> join языковой версии контента и так для каждой галереи коих на странице может быть много. Если например у галереи сделать поле tpl куда записывать уже свормированный HTML код галлереи и отдавать ее всю одним полем это норм?

таблицу для каждого языка - так себе практика

вот короче хз мож глушить эту хуйню как-та можна я хз )

А по поводу этого вопроса Если например у галереи сделать поле tpl куда записывать уже свормированный HTML код галлереи и отдавать ее всю одним полем это норм? это называет кеширование и никакого отношения к галерее не имеет http://www.yiiframework.com/doc-2.0/yii-filters-pagecache.html

норм! Только если верстка табличная

Не понял, если честно. Верстку я буду тянуть ту, которая нужна. просто рааставлю в ней поля и звпишу в tpl галереи

карочи в связующей таблице составной праймори ключ category_id | thumb_id. Он уникальный сам по себе. Т.е. нельзя вставить две одинаковые записи. типа 10 | 15 два раза. Но иногда нужно вставить туда весь набор категорий определенной тумбы, в том числе которые уже есть. Т.е. получится что будет вставляться дубль. и тогда вылетает исключение мол такая херь не прокатит запись уже есть. Приходится сначала проверять есть ли запись, и потом уже вставлять.

так тебе нужно оставить валидацию только в php, а в mysql убрать составной внешний ключ, и где нужно - не валидировать Или еще вариант - свой "весь набор категорий определенной тумбы" связывать через другую таблицу. Второй вариант мне больше нравится, потому как принцип единой ответстванности и все такое

так тебе нужно оставить валидацию только в php, а в mysql убрать составной внешний ключ, и где нужно - не валидировать Или еще вариант - свой "весь набор категорий определенной тумбы" связывать через другую таблицу. Второй вариант мне больше нравится, потому как принцип единой ответстванности и все такое

зачем через другую, если эта пойдет. связь классическая "многие ко многим"

убирать ключ тоже не вариант. индекс же

Не понял, если честно. Верстку я буду тянуть ту, которая нужна. просто рааставлю в ней поля и звпишу в tpl галереи

я сказал сарказм. Конечно плохо хранить верстку в бд, да еще и галереи

зачем через другую, если эта пойдет. связь классическая "многие ко многим"

а тебе обязательно свои тумбы вообще хранить или ты можешь их запросом сформировать и закешировать?

А по поводу этого вопроса Если например у галереи сделать поле tpl куда записывать уже свормированный HTML код галлереи и отдавать ее всю одним полем это норм? это называет кеширование и никакого отношения к галерее не имеет http://www.yiiframework.com/doc-2.0/yii-filters-pagecache.html

Кэш, на сколько мне известно сработает после первой отгрузки. А вопрос как раз, как уменьшить время отгрузки в целом

угараешь чтоль ) конечно обязательно. расчет на 60млн тумб

я сказал сарказм. Конечно плохо хранить верстку в бд, да еще и галереи

Вот я и спрашиваю, тоже как-то не айс ощущения)

Вообще, если собирать поля с 5 - 6 таблиц по 4 - 5 раз на страницу это сильно плохо? И надо ли это лечить? Или кэш это и есть решение проблемы?

угараешь чтоль ) конечно обязательно. расчет на 60млн тумб

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

ясно. связь "многие ко многим" тебе ни о чем не говорит ))

впервые слышу. ты че-т выдумал

https://en.wikipedia.org/wiki/Many-to-many_(data_model)

Эм, many-to-many это мне? Не понял просто. Так-то в курсе) Я справишию про 5 -6 запросов, которые и используют связь, что бы собрать все поля

Если запросы простые - то не накладно.

Вообще, если собирать поля с 5 - 6 таблиц по 4 - 5 раз на страницу это сильно плохо? И надо ли это лечить? Или кэш это и есть решение проблемы?

что значит собирать поля? джойн? Если медленно будет - денормализуй У тебя абстрактный вопрос про таблицы. Html зранить в бд для построения галереи - это плохо

Во, пошел конструктив)

Если запросы простые - то не накладно.

он говорит очень много картинок хранить в бд Хранить картинки в бд - уже должно быть накладно

Короче, я так понял идея с HTML отстой. Делаем по старинке

Не картинки. Путь к ним и мету всякую. Тянем их потом через behavior

А нафиг хранить путь, почему не генерить?

Сорян, не так выразился. Не путь. Имя файла кароч. Генерим путь и тащим мету как раз через behavior

Вопрос просто в другом. Этой меты дофига

Как ее лучше хранить. Я об этом спрашивал

many-to-many наверное же

Вот. Сферический конь в вакууме. Есть одна галерея. В ней 5000 имаг. У каждой имаги 9 - 10 полей с инфой. Плюсом четыре языковые версии этой инфы. Способа лучше чем делать одну общую таблицу и герез foreigh keys четыре языковые таблицы нет?

Посоветуйте CSS инлайнер на PHP. Нужно подобное делать: https://templates.mailchimp.com/resources/inline-css/

Вот. Сферический конь в вакууме. Есть одна галерея. В ней 5000 имаг. У каждой имаги 9 - 10 полей с инфой. Плюсом четыре языковые версии этой инфы. Способа лучше чем делать одну общую таблицу и герез foreigh keys четыре языковые таблицы нет?

nosql

+ cache

Вообще это тупо рассчитывать коня в вакууме

nosql

Думаю в эту сторону. Но к nosql пока не готов. надеялся, что есть какое-то другое решение.

С конем надо работать по факту

Нормализации бд и индексов на первых порах достаточно

Вот. Сферический конь в вакууме. Есть одна галерея. В ней 5000 имаг. У каждой имаги 9 - 10 полей с инфой. Плюсом четыре языковые версии этой инфы. Способа лучше чем делать одну общую таблицу и герез foreigh keys четыре языковые таблицы нет?

а в чем проблема то?

а в чем проблема то?

В голове

1 ко многим тут связь

Все думают, что на их проекте завтра int закончится

тем более что он unsigned

да, когданить кончится )

Все думают, что на их проекте завтра int закончится

И начнутся unsigned bigint

вот проблема 38 года... это да

но до нее еще 20 лет

Знаю. И технологию знаю и реализовывал ее не раз. Просто лично мне это кажется прожорливой тратой ресурсов. Вот и подумал может есть какие-то способы лучше.

Знаю. И технологию знаю и реализовывал ее не раз. Просто лично мне это кажется прожорливой тратой ресурсов. Вот и подумал может есть какие-то способы лучше.

нормальная трата ресурсов

языки тока не 4 таблицы нада, а в одну

Как раз время появилось. Читаю форумы ищу решения, но везде примерно одно и тоже. Либо nosql либо пиши связи и нормализуй

языки тока не 4 таблицы нада, а в одну

Это очень спорный ворос

Та при такой избыточности одной ок

Это очень спорный ворос

Нет

ERROR: S client not available

Это очень спорный ворос

не спорный нифига

Смотри, может ли быть вариант что тебе нужно два языка сразу?

вот проблема 38 года... это да

Вроде не проблема)

Это очень спорный ворос

Лол

4 таблицы как минимум с одним избыточным полем - название файле

ид сообщения | ид языка | сообщение

А-то и двумя - бо ещё нужно ж хранить айди по которому связка

и не нада распаляться на 100500 таблиц

Лучше 1 таблица

Базарю

Две причины почему описал выше

ид сообщения | ид языка | сообщение

домен еще, иначе заблудишься в id

Базарю

А теперь представь, что тебе нужно довать еще один язык

добавить

И понеслась

Тю, и шо

Добавил колонку / две

Чем трабл?)

а если языков будет не 5 а скажем 10-15

а если больше ?

домен еще, иначе заблудишься в id

че за домен? )

А если 4 все таки?)))

Колонку добавил? Добавь на legacy проекте колонку. покрашится все

У вас "а если" слишком глобальные

языки можно в json держать (у postgresql есть удобный тип данных jsonb)

Если языков 150 тогда да

языки можно в json держать (у postgresql есть удобный тип данных jsonb)

В мускл тоже есть уже

Если языков 150 тогда да

Тут же момент избыточности, для 4 ок 1 табла

В мускл тоже есть уже

Поддерка плохая у хостеров

заказчики народ типа обезъяна с гранатой сейчас 4 потом блин а теперь мы еще идиш хотим китайский японский да и наврное еще с 10 языков добавить а мы можем это сами сделать ?

языки можно в json держать (у postgresql есть удобный тип данных jsonb)

ебани поиск по ним :D

заказчики народ типа обезъяна с гранатой сейчас 4 потом блин а теперь мы еще идиш хотим китайский японский да и наврное еще с 10 языков добавить а мы можем это сами сделать ?

+100500