AH
Я же выше кинул
Всё, увидел
Size: a a a
2021 January 28
И
Всё, увидел
вот почище будет и полегче
И
без вендора и .idea
P
минус 35 метров, нормально
И
все равно завтра буду с нуля писать заново. Я понял, что держать пути к файлам картинок в отдельной таблице - не лучшая идея. Везде будет два запроса в БД вместо одного. Тот же user - надо аватарку - + один запрос в БД. Я понимаю - товары - несколько изображений, но у меня несколько сущностей, где всегда будет только одно изображений. Не вижу смысла хранить их отдельно
И
и даже главное изображение товара буду вместе с Товаром хранить
И
потому что много где страниц, где есть товар + главная картинка
И
нефиг плодить запросы в БД на ровном месте
v
все равно завтра буду с нуля писать заново. Я понял, что держать пути к файлам картинок в отдельной таблице - не лучшая идея. Везде будет два запроса в БД вместо одного. Тот же user - надо аватарку - + один запрос в БД. Я понимаю - товары - несколько изображений, но у меня несколько сущностей, где всегда будет только одно изображений. Не вижу смысла хранить их отдельно
Странно, файловые реестры как-то же работают и не хранят данные рядом с мета данными )
И
Странно, файловые реестры как-то же работают и не хранят данные рядом с мета данными )
ну все равно не вижу смысла
И
проект небольшой, типа магазина
VG
проект небольшой, типа магазина
а если разрастётся?
🎃
все равно завтра буду с нуля писать заново. Я понял, что держать пути к файлам картинок в отдельной таблице - не лучшая идея. Везде будет два запроса в БД вместо одного. Тот же user - надо аватарку - + один запрос в БД. Я понимаю - товары - несколько изображений, но у меня несколько сущностей, где всегда будет только одно изображений. Не вижу смысла хранить их отдельно
ты про спатие?
И
ты про спатие?
ну типа такого, сделал полиморфную связь
v
проект небольшой, типа магазина
так и в чем проблема отдельного реестра под файлы и связь с ним от моделей где есть файлы?
На странице примерно 2 модели связанные с реестром итого 4 запроса в бд с жадной загрузкой. А если еще кеширование предусмотреть...
Имхо экономия на спичках. Как же третья нормальная форма ?
На странице примерно 2 модели связанные с реестром итого 4 запроса в бд с жадной загрузкой. А если еще кеширование предусмотреть...
Имхо экономия на спичках. Как же третья нормальная форма ?
И
так и в чем проблема отдельного реестра под файлы и связь с ним от моделей где есть файлы?
На странице примерно 2 модели связанные с реестром итого 4 запроса в бд с жадной загрузкой. А если еще кеширование предусмотреть...
Имхо экономия на спичках. Как же третья нормальная форма ?
На странице примерно 2 модели связанные с реестром итого 4 запроса в бд с жадной загрузкой. А если еще кеширование предусмотреть...
Имхо экономия на спичках. Как же третья нормальная форма ?
а аватарка пользователя не часть модели User?
v
а аватарка пользователя не часть модели User?
Нет, это файл связанный с пользователем.
И
Нет, это файл связанный с пользователем.
файл лежит в папке, а модель лишь знает имя файла (путь) и знает есть он или нет
Y
так и в чем проблема отдельного реестра под файлы и связь с ним от моделей где есть файлы?
На странице примерно 2 модели связанные с реестром итого 4 запроса в бд с жадной загрузкой. А если еще кеширование предусмотреть...
Имхо экономия на спичках. Как же третья нормальная форма ?
На странице примерно 2 модели связанные с реестром итого 4 запроса в бд с жадной загрузкой. А если еще кеширование предусмотреть...
Имхо экономия на спичках. Как же третья нормальная форма ?
Нормальные формы это конечно хорошо, но не будем также забывать и о физическом представлении данных.