Есть папки, в каждой папке находятся картинки (вложенные папки игнорируем). У каждой папки есть свой список тегов. У каждой картинки в каждой папке есть список присвоенных тегов (эти теги должны быть только теми, которые доступны в папке). Также у каждой папки есть атрибут, запоминающий последнюю открытую картинку.
Сделал как на пике, но что-то подсказывает, что это какая-то хуйня
Забыл написать, что также нужно запоминать последнюю открытую папку.
А что сделать то надо?
Таки тут и так используется Many-to-Many в трех самых правых таблицах
Схему базы данных, что вполне очевидно, я думаю
Иди на хуй
Мимо базы данных
Что за таблица с одним полем, нахуй она тебе нужна? По ключам немного напутал, попробуй работать с этой базой, так ты поймёшь где что как должно быть
В Directory не нужно поле ImageId, так как односторонняя связь
ImagesTags лучше сделать так же как в DirectoryTags, с одной связью на Image
Вообще гугли uni-directional, bi-directional связи, many-to-many, one-to-many, many-to-one
Че за прога?
> Что за таблица с одним полем, нахуй она тебе нужна?
Где/как тогда лучше хранить некоторые настройки программы? Предполагалось, что это будет таблица с одной записью, в которой будут все нужные настройки
> По ключам немного напутал
Можно немного подробнее?
В DirectoryTags (которая должна называться DirectoriesTags) поле Id должно быть Integer, конечно же
Попутно вкатываюсь в нейронки в примитивном их виде (python + keras), а это прога нужна для того, чтобы набрать обучающих данных
При чем базы данных? Такие приколы используются при проектировании систем, а ты просто данных хочешь напарсить. Почему питоном это не сделаешь? Математика у тебя на каком уровне? Многомерный матан знаешь? Случайные процессы хотя бы до марковских процессов, эргодической теории и стохастических дифуров?
Про ключи тут расписали
>>239902669
Настройки? Какие нахуй настройки? База данных это само по себе хранилище информации и её настройки привязаны к ней ну типо, если что то типо хранимых процедур то не лезь пока, не поймёшь пока запросы нормальные не будешь делать
Кстати если вкатываешся нахуй тебе такой пример выебистый? Не в плане решения а условия
Обучающие данные набиваются ручками, поэтому просто напарсить их не выйдет. База данных, чтобы не плодить стопицот файликов с данными там, где они не нужны (кроме этой программы, естессна)
Мда.
Тебе бы кодить для начала научиться хотя бы на уровне второкурсника прикмата, а потом уже куда-то дальше идти.
Под настройками я имел ввиду настройки программы, которые так или иначе связаны с самой БД, пока что там только последняя использованная папка, чтобы при запуске проги каждый раз не указывать папку
Я вполне допускаю, что я еблан и все такое, но только обоснуй, что не так и как фиксить?
Ну я честно говоря в замешательстве. Ты, видимо, собираешься проставлять тэги картинкам? Ну так запили себе скрипт на 15 строчек для этого и все картинки держи в одной папке а мапу картинка- тэги в другой. В чем проблема? Какие нахуй БД? Какие нахуй проектировщики БД?
Все так, но в каждой папке допустимы только свои теги, пока у меня сделано так:
Рядом с прогой лежит файлик config, в котором указан путь к последней использованной папке
В каждой папке, открытой хотя бы один раз есть 3 файла:
tags - теги, допустимые в этой папке + краткие описания для каждого
images - названия всех картинок и соответствующие ей теги
config - здесь хранится индекс последней использованной картинки
В папке ~40к файлов и во время загрузки/выгрузки данных это работает очень медленно, к тому же, все это приходится хранить в оперативе
Ну и оставь так. Или конфиги сложи в один файл.
>~40к файлов и во время загрузки/выгрузки данных это работает очень медленно
Ну либо так и должно быть, либо ты накодил говно. Истина, скорее всего, где-то посередине.
> тому же, все это приходится хранить в оперативе
БД локальные по твоему будут быстрее это делать или хранить это говно не в оперативе?
Так, что за программа? Мне не понятно что ты хочешь делать. Программа это СУБД или программа которая работает с бд?
Меня скорее напрягает, что из-за этого страдает переносимость, я бы хотел запилить такое: БДшка хранится у меня на компутере (сервере), другие пользователи (те, кто будут набивать БД) запрашивают данные о файле и допустимые теги, проставляют теги и отправляют обратно на сервер, где это дело сохраняется в БД.
Конечно, можно тупа отправить каждому экземпляр программы, свою часть файликов и все такое, но это не особо удобно
На текущем этапе это пока что "сделать хотя бы что-то, работающее у себя"
Прога, которая работает с БД
Подробнее тут:
>>239902894
>>239904084
Медлительность связана с тем, что при каждой загрузке данных из папки проверяется не были ли добавлены/удалены файлы, конечно это можно было бы сделать через хэши, но мне было максимально впадлу (в БД же достаточно добавить индексы)
>БДшка хранится у меня на компутере (сервере), другие пользователи (те, кто будут набивать БД)
Для этого на питоне есть фласк. Для этого есть готовые бд интегрированные с питоном, разной степени модности. Нахуй тебе схема БД?
Как условный пользователь получает файл? С вводом пользователем тегов не вижу проблем, ограничения просто в самом поле ввода тега допустим
> готовые бд интегрированные с питоном
Чего блять?
Может быть ты имел ввиду ORM'ки, но это все равно не "готовые интегрированные БД", да и для ORM'ок нужно все равно делать схему
Загружает его с сервера, очевидно (можно сделать, чтобы например, сразу подгружались 5-10 ближайших файлов, чтобы не грузить каждую картинку по отдельности)
Мы, видимо, по разному интеграцию понимаем. Я говорю про всевозможные носукль с питон апи.
Еще раз. Схемы необходимы только в огромных, многоступенчатых проектах с разными пользователями и их потребностями.
Я не про теорию, а про практику. Т.е сейчас по одной идут и все работает медленно? Пробуй советы по ключам выше, если не поможет то думай над запросами тут может быть масса вариантов
Да ну? Может схемы полезны новичкам для понимания? Да и в хуйне побольше чем практика новичка можно делать схему что была целая картина, и не в голове
Все, что я видел ранее на GitHub'e от мал до велика делалось с использованием ORM'ок типа SQLAlchemy (в случае питона) и EF/EF Core (в случае шарпов), а когда БД совсем маленькая, то не гнушаются использовать и простые SQL запросы
Следуй единому стилю, прохвост:
DirectoriesImages -> DirectoryImages
ImagesTags -> ImageTags
Теги вообще в отдельную таблицу Tags вынести, потом в DirectoryTags и в ImageTags юзать tag_id из общей таблицы Tags, дабы не дублировать текстовый понос
в таблице Directory:
imageId -> last_uploaded_image_id
иначе не понятно нихера что это за imageId
в таблице ProgramSettings:
LastDirectory -> last_opened_dir_id
иначе непонятно что за LastDirectory
> а когда БД совсем маленькая, то не гнушаются использовать и простые SQL запросы
И даже когда не маленькая. Использовать орм или нет - вопрос не зависящий от базы данных и её размеров.
Чтобы получить последнюю директорию ты либо:
a) Смотришь на ид в directories и берёшь directories_ids_seq - 1
б) Селектишь первую строчку с таблицы directories, отсортировав их в последовательности created_at || updated_at
Главное не забывай обновлять updated_at.
Теги у директорий не нужны. Получаешь ты их запросом через агррегирование записей из images и последующим запросом к tags я бы мб даже убрал imageTags и сделал их колонкой в images
Таблица директорий не должна иметь референс на картинки. Логика тут простая: directory has_many images && image belongs_to directory. Не наоборот.
По этому таблица картинок содержит в себе референс на директории, а не наоборот.
А так вообще ты изобретаешь велосипед. Вместо всего этого дрочева иди учить рельсы, их гайд охуенное представление даст о референсах, связях, бд и работе с ней через их орм.
Очевидно проебал обращение к опу.
>>239902102 (OP)
>Чтобы получить последнюю директорию ты либо...
И всё последующее было адресовано опу. Сорян.
И с картинкой проебался... Поторопился.
Ты как-то херово задачу прочитал дружище, все правильно он сделал, с несколькими мелкими косяками
Где он правильно сделал? Бд не нормализована. Из 5 таблиц 3 лишние по сути. Даже если предположить, что он полный аутист и делает вложенные директории, то получается, что ему нужно добавить только parent id чтобы построить эту связь.
С тегами вообще не ясно что он хочет делать. У него теги и к картинкам относятся, и к директориям. Если сущность тегов одинаковая, то тут вообще должна быть одна табличка tags и связующие т.к. это чистейший HABTM тогда.
Я ему об этом выше и написал, нужна таблица Tags, остальное все логично, левых таблиц не наблюдаю исходя из того, как я понял задачу
Единственные правильные с точки зрения нормализации бд решения, которые он принял - табличка директорий и табличка картинок файлов разделены. Всё остальное - какой то огород. Как и не понятно, что он собирается хранить в Images.image::text колонке, так и не понятно, что он вкладывает в функционал тегов. Не понятно зачем он вообще учит чистую бд вместо того чтобы вкатиться в разработку через изучение каких-нибудь фреймворков типа реилс. Велосипеды велосипедики.
В общем, я своё мнение высказал и теперь попиздовал дальше. Успехов.
У тебя должны быть отдельно таблицы
Images: id, name, directory_id, ...
Directories: id, name, path, last_opened_at, last_opened_image_id, ...
Tags: id, name, ...
Для них пилишь джоин тейблы
ImageTags: image_id, tag_id
DirectoryTags: directory_id, tag_id
Рестриктишь поле tag_id в ImageTags на те, которые есть в DirectoryTags у данной дирректории, которая у тебя есть по directory_id.
А что пилишь-то собственно?
> ProgramSettings табличку с референсом на запись в таблице директорий чтобы понять, что челик походу никогда ни через ОРМ не работа, ни SQL запросы не писал и не понимает как работает бд раз трекает последнюю запись таким образом.
Да это ты просто никогда не думал наверное головою. Давай резюмируем
Есть куча папок, надо трекать последнюю открытую. Ты предлагаешь по нажатию на папку на условном фронте обновлять в БД поле updated_at таблицы Directories датой (8 байт). Чтобы потом выбрать последнюю открытую - тебе надо сортировать (*) таблицу Directories по updated_at.
Есть и другой вариант - обновить в таблице ProgramSettings поле last_opened_folder_id IDхой (4 байта). Почему ты не рассматриваешь этот вариант в принципе - для меня загадка, ведь он очевиден. Чтобы потом выбрать последнюю открытую тебе нихуя не надо сортировать, вот ведь внезапно, да?
> что он собирается хранить в Images.image::text
Ссылку на картинку, залитую на какой-то хостинг, тоже мне бином Ньютона
> Не понятно зачем он вообще учит чистую бд вместо того чтобы вкатиться в разработку через изучение каких-нибудь фреймворков типа реилс
Это вообще пиздетс мысль умная
> теперь попиздовал дальше
Давай, скатертью
Как он без Tags будет ограничивать доступные теги для файла из папки?
Ну а так, если по заданию нужно именно айди хранить, то сойдёт. Только у таблицы пересечений должен быть еще свой айди.
> хочет использовать целую таблицу в бд для одной единственной записи
> не хочет делать селект с сортировкой и лимитом
> не слышал про функции-триггеры в бд, которые могут даже анус дёрнуть
И самое ироничное
> огрызается
Пошёл нахуй в /pr/, клоун.
> хочет использовать целую таблицу в бд для одной единственной записи
Таблица называется Preferences, там может быть много полей. То, что OP там одно указал, это не значит что оно там будет одно
> не хочет делать селект с сортировкой и лимитом
Селект с сортировкой и лимитом или селект без сортировки, какой же вариант правильный? Конечно же тот, что с сортировкой, ведь я ебанутый
> не слышал про функции-триггеры в бд, которые могут даже анус дёрнуть
Опять сложный выбор - введение нахуй ненужного поля updated_at и вызов триггера при его обновлении или атомарный update, я бы тоже выбрал update с триггером, ведь как я написал выше - я ебанутый
И самое ироничное
> иронизирует
выдумывая как забить гвоздь экскаватором
Укатывайся, макака
Ты нахуй серишь, клоун? Preferences в бд. Ебануться! Селект с сортировкой делать не хочу, а селект из preferences хочу. Как ты там сделаешь? Для каждого параметра будешь делать колонку? И всё в одной записи, да? Или сделаешь ключ-значение, создав тем самым свой велосипед в виде ключ-значение бд в реляционной бд?
Нахуй ты вообще так жёстко серишь себе в штаны? Это настолько бред, что я уже думаю, что ты просто так жирнюще троллишь.
Ты бы вначале с субд ознакомился, узнал бы возможности функций, триггеров, индексов и тогда у тебя не будет вопросов о селекте. Охуеть, возмущается селектам. Где это видано чтобы из бд получали данные... Да и не просто данные, а ещё и ОТСОРТИРОВАННЫЕ! Возмутительно! SIC!
Покормил
Мы либо друг друга не понимаем, либо кто-то из нас ебанутый
Давай представим что у него есть сайт, где эти папки с картинками выводятся. У сайта есть настройки - типа цвет фона, заголовок h1, последняя открытая папка. Где блять их еще хранить если не в БД? В чем проблема каждую из настроек записать в отдельное поле в таблице Preferences, я не понимаю?
Открывает он этот ебучий сайт свой с папками и перед открытием селектит ту самую запись из
preferences, надо ведь фон подкрасить, так он узнает последнюю открытую папку.
> Ты бы вначале с субд ознакомился, узнал бы возможности функций, триггеров, индексов и тогда у тебя не будет вопросов о селекте. Охуеть, возмущается селектам. Где это видано чтобы из бд получали данные...
Ты хуйню несешь, есть большая разница как писать и как получать данные. Запрос с сортировкой всегда тяжелее чем тупой и прямой селект по ID. А триггер в данном случае - это просто пиздец, посчитай сам
1. Обновляешь поле updated_at у папки
2. Срабатывает триггер
=== 2 операции, пихуй что в рамках одной транзакции ===
==== VS =====
1. Обновляешь одно поле в таблице Preferences
=== 1 операция ===
Где логика блять потерялась? Нахуя 2 операции?