Правильно ли я создала БД с такими названиями таблиц и нужно ли всегда делать модели для БД для миграции?
Создаю приложение с использованием БД и хочу сделать хорошо, а не на "тяп-ляп". Это мой первый опыт и столкнулась с такой историей. Помогите разобраться, пожалуйста.
1. Названия таблиц.
У меня есть тестовая БД. Чтобы её создавать, я сделала отдельный класс и функции, в функциях прописала все запросы с SQLite, типа CREATE TABLE'ов и тд. Создание БД происходит в 2 этапа: сначала создаются таблицы, которые должны быть всегда в этой БД. а затем, по мере добавления контента (точнее "очень крупных сущностей в проект") в БД, создаются ещё несколько таблиц. У этих новых таблиц специфические имена (такая идея пришла мне для того, чтобы избежать фильтра по одному полю, т.к. предполагается, что данных может быть очень много).
Пример:
Таблица, которая должна быть всегда, называется "page", у неё такие поля, например, id, s_name.
А по мере добавления крупных сущностей (от 1 до 5 предполагается), в таблице page появляются данные, например:
"1, q_test"
"2, w_test"
и две таблицы q_test и w_test соответственно.
Таким способом я пыталась разделить две сущности, чтобы не добавлять в запрос "WHERE s_name = 'q_test' ", например.
И вопрос, нормально ли делать таким образом таблицы или это очень плохая идея и лучше добавить поле и по нему фильтровать, а не брать готовое (т.к. все данные разделены по таблицам)?
2. Модели и миграции
Я знаю, что в правилах запрещено задавать несколько вопросов, но этот вопрос вытекает из 1ого.
Всю ту БД я создавала вручную каждый раз. И при добавлении новой сущности добавлялись новые таблицы в БД.
Сначала меня всё устраивало, но потом я подумала, что нужна веб часть, которой ранее не было, и далее я столкнулась с миграциями в БД.
Проблема в том, что создавая таблицы самостоятельно (напрямую работая с модулем sqlite3 в python), я нигде не описывала модели БД, как получилось в статье по ссылке выше. Более того, эти модели активно стали участвовать в миграциях.
Нужно ли мне всю схему БД переделать под модели или можно миновать модели и в ручную\напрямую добавлять данные в БД ? (sqlite в моём случае). И как быть с миграциями, чтобы синхронизировать копии БД на разных машинах?
Помогите с этим разобраться :)
Если напишите план действий по исправлению ужасов с БД, наверняка они тут есть, буду признательна!
Стабилизируйте бд . Это главный совет. Миграции лучше применять позже. Есть куча утилит для синхронизации инстансов, в том числе и с разными схемами. В нормальном случае процесс применения миграций выглядит так: вы последовательно выполняете скрипты миграций по порядку. После обновляете кол приложения.
Вечер добрый! Поясните что означает "стабилизировать БД" ?
У меня просто ранее миграций не было, по сути я их сделала "сама в файле main". Полагаю, вариант не очень.
nullnull, Стабилизировать это создать схему по вашей предметной области, максимально ее проработав до уровня MVP. Дальше итерировать по этапам продукта, наращивая функционал.
По моему мнению SCRUM переоценен, а вот ВОДОПАД наоборот необоснованно забыт, особенно в маленьких проектах и при отсутствии опыта.
Владимир Коротенко, а, ну этот этап как раз пройден в этом плане. ранее я делала проект без веб-интерфейса, теперь делаю веб-интерфейс, а там "а давайте для flask-a добавим библиотек по управлению БД. а давайте миграции, а давайте то, сё". И вот я подумала: правильно ли вообще я организовала одну часть таблиц как... "динамичные" таблицы (названия таблиц зависит от сущностей, которые будут там заводиться), и если это ещё нормально, то нормально ли вписывать тогда миграции, ну, чтобы были, или если есть БД, которая уже не изменяет схему раз в час, то ей и миграции на самом деле не нужны?
И вот этот вопрос меня начал беспокоить.
А ещё в приложении теперь появились модели. а ранее я их не использовала - хорошо ли жить с моделями или плохо? - не понятно.
Я сужу по себе в EF есть 2 подхода CodeFirst & DatabaseFirst
Есть еще и Daper он вообще ближе к чистому SQL мапит все как ему напишут.
В общем случае сущьности меняются не часто. Впрочем в вашем случае можно читерить, держать 2 подключения в коде и изредка полностью мигрировать данные из базы в базу, но это на этапе разработки
Простой
