SiZE
А по поводу этого вопроса
Если например у галереи сделать поле tpl куда записывать уже свормированный HTML код галлереи и отдавать ее всю одним полем это норм?
это называет кеширование и никакого отношения к галерее не имеет
http://www.yiiframework.com/doc-2.0/yii-filters-pagecache.html
Screamie
норм! Только если верстка табличная
Не понял, если честно. Верстку я буду тянуть ту, которая нужна. просто рааставлю в ней поля и звпишу в tpl галереи
Niko
карочи в связующей таблице составной праймори ключ category_id | thumb_id.
Он уникальный сам по себе. Т.е. нельзя вставить две одинаковые записи. типа 10 | 15 два раза. Но иногда нужно вставить туда весь набор категорий определенной тумбы, в том числе которые уже есть. Т.е. получится что будет вставляться дубль. и тогда вылетает исключение мол такая херь не прокатит запись уже есть. Приходится сначала проверять есть ли запись, и потом уже вставлять.
так тебе нужно оставить валидацию только в php, а в mysql убрать составной внешний ключ, и где нужно - не валидировать
Или еще вариант - свой "весь набор категорий определенной тумбы" связывать через другую таблицу.
Второй вариант мне больше нравится, потому как принцип единой ответстванности и все такое
The Ant
так тебе нужно оставить валидацию только в php, а в mysql убрать составной внешний ключ, и где нужно - не валидировать
Или еще вариант - свой "весь набор категорий определенной тумбы" связывать через другую таблицу.
Второй вариант мне больше нравится, потому как принцип единой ответстванности и все такое
зачем через другую, если эта пойдет. связь классическая "многие ко многим"
The Ant
убирать ключ тоже не вариант. индекс же
Niko
Не понял, если честно. Верстку я буду тянуть ту, которая нужна. просто рааставлю в ней поля и звпишу в tpl галереи
я сказал сарказм. Конечно плохо хранить верстку в бд, да еще и галереи
Niko
зачем через другую, если эта пойдет. связь классическая "многие ко многим"
а тебе обязательно свои тумбы вообще хранить или ты можешь их запросом сформировать и закешировать?
Screamie
А по поводу этого вопроса
Если например у галереи сделать поле tpl куда записывать уже свормированный HTML код галлереи и отдавать ее всю одним полем это норм?
это называет кеширование и никакого отношения к галерее не имеет
http://www.yiiframework.com/doc-2.0/yii-filters-pagecache.html
Кэш, на сколько мне известно сработает после первой отгрузки. А вопрос как раз, как уменьшить время отгрузки в целом
The Ant
угараешь чтоль ) конечно обязательно. расчет на 60млн тумб
Screamie
я сказал сарказм. Конечно плохо хранить верстку в бд, да еще и галереи
Вот я и спрашиваю, тоже как-то не айс ощущения)
Screamie
Вообще, если собирать поля с 5 - 6 таблиц по 4 - 5 раз на страницу это сильно плохо? И надо ли это лечить? Или кэш это и есть решение проблемы?
Niko
угараешь чтоль ) конечно обязательно. расчет на 60млн тумб
я не знаю что там и почему оно повторяется, но я пересмотрел бы структуру бд.
Дополнительные 60млн полей в одной таблице не такая мелочь
The Ant
ясно. связь "многие ко многим" тебе ни о чем не говорит ))
Niko
впервые слышу. ты че-т выдумал
The Ant
https://en.wikipedia.org/wiki/Many-to-many_(data_model)
Niko
Screamie
Эм, many-to-many это мне? Не понял просто. Так-то в курсе) Я справишию про 5 -6 запросов, которые и используют связь, что бы собрать все поля
Antony
Если запросы простые - то не накладно.
Niko
Вообще, если собирать поля с 5 - 6 таблиц по 4 - 5 раз на страницу это сильно плохо? И надо ли это лечить? Или кэш это и есть решение проблемы?
что значит собирать поля? джойн? Если медленно будет - денормализуй
У тебя абстрактный вопрос про таблицы. Html зранить в бд для построения галереи - это плохо
Screamie
Во, пошел конструктив)
Niko
Если запросы простые - то не накладно.
он говорит очень много картинок хранить в бд
Хранить картинки в бд - уже должно быть накладно
Screamie
Короче, я так понял идея с HTML отстой. Делаем по старинке
Screamie
Не картинки. Путь к ним и мету всякую. Тянем их потом через behavior
Алексей
А нафиг хранить путь, почему не генерить?
Screamie
Сорян, не так выразился. Не путь. Имя файла кароч. Генерим путь и тащим мету как раз через behavior
Screamie
Вопрос просто в другом. Этой меты дофига
Screamie
Как ее лучше хранить. Я об этом спрашивал
Niko
many-to-many наверное же
Screamie
Вот. Сферический конь в вакууме. Есть одна галерея. В ней 5000 имаг. У каждой имаги 9 - 10 полей с инфой. Плюсом четыре языковые версии этой инфы. Способа лучше чем делать одну общую таблицу и герез foreigh keys четыре языковые таблицы нет?
Сергей
Посоветуйте CSS инлайнер на PHP. Нужно подобное делать: https://templates.mailchimp.com/resources/inline-css/
SiZE
+ cache
SiZE
Вообще это тупо рассчитывать коня в вакууме
Screamie
nosql
Думаю в эту сторону. Но к nosql пока не готов. надеялся, что есть какое-то другое решение.
SiZE
С конем надо работать по факту
SiZE
Нормализации бд и индексов на первых порах достаточно
The Ant
The Ant
1 ко многим тут связь
SiZE
Все думают, что на их проекте завтра int закончится
The Ant
тем более что он unsigned
The Ant
да, когданить кончится )
The Ant
вот проблема 38 года... это да
The Ant
но до нее еще 20 лет
Screamie
Знаю. И технологию знаю и реализовывал ее не раз. Просто лично мне это кажется прожорливой тратой ресурсов. Вот и подумал может есть какие-то способы лучше.
The Ant
The Ant
языки тока не 4 таблицы нада, а в одну
Screamie
Как раз время появилось. Читаю форумы ищу решения, но везде примерно одно и тоже. Либо nosql либо пиши связи и нормализуй
Trokhym
Та при такой избыточности одной ок
Trokhym
Смотри, может ли быть вариант что тебе нужно два языка сразу?
Trokhym
4 таблицы как минимум с одним избыточным полем - название файле
The Ant
ид сообщения | ид языка | сообщение
Trokhym
А-то и двумя - бо ещё нужно ж хранить айди по которому связка
The Ant
и не нада распаляться на 100500 таблиц
Trokhym
Лучше 1 таблица
Trokhym
Базарю
Trokhym
Две причины почему описал выше
Mihail
Screamie
добавить
Screamie
И понеслась
Trokhym
Тю, и шо
Trokhym
Добавил колонку / две
Trokhym
Чем трабл?)
👻
а если языков будет не 5 а скажем 10-15
👻
а если больше ?
Trokhym
А если 4 все таки?)))
Screamie
Колонку добавил? Добавь на legacy проекте колонку. покрашится все
Trokhym
У вас "а если" слишком глобальные
Никита
языки можно в json держать (у postgresql есть удобный тип данных jsonb)
Trokhym
Если языков 150 тогда да
Trokhym
языки можно в json держать (у postgresql есть удобный тип данных jsonb)
В мускл тоже есть уже