что плохого в переименовании?

Потому что это не является проблемой. И ты не знаешь, когда у тебя внезапно закончится разработка и начнётся деплой в прод, как показывает практика. Переименование плохо тем, что ты можешь, во-первых, случайно сломать миграции (и даже это не заметить), во-вторых, будут проблемы, если ты работаешь над проектом не один. Ты ж не будешь других разрабов просить каждый раз БД пересоздавать и все миграции прогонять. Как они вообще узнают, что ты что-то переименовал?

Я обычно создаю изначально всё миграциями. И вообще любые изменения - новая миграция. Ни разу ни с какими проблемами не сталкивался. Ну, кроме случая, когда для индекса CONCURRENTLY забыл, но это другая история вообще

файлик ридми прикладываю) с ломанием, на там вроде не ломается, но хз конечно

Ридми? И кто его читает после каждого git pull? Если тебя пугает много файлов миграций, то забей, это вообще не страшно. У меня их сейчас в проекте больше 200 штук - и всё ок.

понял, спасибо, обычно не количество пугает а то что открыл миграцию и там не полные данные по таблице, а так полные

но количество конечно да тоже фактор)

Когда их станет сильно много, делаешь так:
1) Снять структурный дам с прода
2) Файл дампа положить в репозиторий проекта
3) Создать миграцию, которая читает весь SQL из этого файла и применяет его
4) Подключиться вручную к нужным БД и прописать эту миграцию, как применённую
5) Удалить все файлы миграций, кроме последней (она становится новой миграцией инициализации)
Всё!)

3-й шаг нужен, чтобы любой новый разраб мог локально запустить миграции у себя на компе и получить готовую базу. Ну или если ещё где-то проект развернуть решили

ну кстати хороший способ

Если ты про то, что можно случайно создать таблицу, которая ссылается на ту, которая ещё не существует, то это не страшно, потому что можно после этого создать нужную таблицу и ещё одной миграцией повесить внешний ключ. Кроме того, если ты вот так будешь создавать таблицу, то при отсутствии таблицы books (например) у тебя миграция создания mytable просто не применится, т.к. PosgtreSQL кинет ошибку

CREATE TABLE mytable(
            user_id INT REFERENCES users(id),
            book_id INT REFERENCES books(id),
            PRIMARY KEY (user_id, book_id)
        )

«Стадия разработки». Вам там поди и ТЗ пишут. Хорошо жить в 2005-м. Доллар по 20.

CREATE TABLE mytable(
            user_id INT REFERENCES users(id),
            book_id INT REFERENCES books(id),
            PRIMARY KEY (user_id, book_id)
        )

ну я то пользуюсь php artisan migrate:refresh до прода, но как вы верно подметили граница сея размыта

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

#вакансия #wildberries #dba #москва

Коллеги всем привет и с наступающими праздниками!

Позиция: DBA в команду Golang разработчиков
Вилка: 200-250 тр на руки
Что для нас важно:
 Знание программных продуктов - PostgreSQL, MSSQL.
 Опыт разработки на T-SQL, pgplsql
 Умение работать с планами запроса

CV можно присылать сюда @aveLestat
https://spb.hh.ru/vacancy/41141323

так DBA или SQL Developer, это вообще не одно и тоже

dba

Там еще не написали, что в конторе перманентный армагеддец происходил или происходит,
людей за ворота выбрасывают легко и непринужденно.

кто же такое будет писать в описании вакансии)

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