Y
Схема особенно важна, когда требования очень быстро меняются :)
Size: a a a
2019 December 23
Y
Иначе становится практически невозможно отследить, что же собственно записано в СУБД и какие данные там могут быть, и в каком формате
Y
И, например, сложно быть уверенным в том, используется ли какое-то поле до сих пор или нет
AK
Версионирование и json решают
Y
Как раз наличие схемы позволяет быстро её менять и при этом иметь контроль над ситуацией
Y
Если у вас итак есть четкое версионирование, то зачем вам JSON :)?
PD
Andrew Komiagin
Версионирование и json решают
А кто мешает все то же делать в PG? Если уж схема мешает.
AE
Ну, там вроде бы не было никаких гарантий.
Как я понял были такие специальные транзакции, которые коммитились асинхронно. Т.е. клиент отправлял данные потоком и через несколько циклов получал ответ: успешно или нет. И можно было по коммиту точно знать, что данные записаны, а по фейлу повторить отправку определённой пачки данных.
Но на тот момент для этого нужна была свежая версия и ещё более сырой сторадж-движок Винил.
Но на тот момент для этого нужна была свежая версия и ещё более сырой сторадж-движок Винил.
PD
Как раз наличие схемы позволяет быстро её менять и при этом иметь контроль над ситуацией
Ну, смена схемы не бесплатная операция...
AK
Все можно и на pg. Для 90% систем его вполне хватит с запасом
Y
Ну да ладно. Это философский вопрос :). Лично мне было очень сложно пользоваться монгой именно из-за отсутствия проверок существования полей, типов и т.д. со стороны базы данных. Особенно весело ждать, пока исполнится аналитический запрос, занимающий 10 минут, чтобы потом осознать, что в имени поля была опечатка :)
PD
Ну, просто с json PG работает ещё лучше монги.
AK
Ну, смена схемы не бесплатная операция...
100%
Y
Ну, смена схемы не бесплатная операция...
В PG — не бесплатная, но есть другие СУБД, где она умеет выполняться на фоне :)
PD
В PG — не бесплатная, но есть другие СУБД, где она умеет выполняться на фоне :)
Нее, везде блокировка вылезает в какой-то момент.
Y
К тому же в PostgreSQL смена схемы часто тоже очень дешёвая, например добавление поля, переименование (хотя переименование не пробовал) по сути только обновляют метаданные таблицы
AK
Тут ещё вопрос в том как поведёт себя приложение когда в бд в фоне миграция))
PD
К тому же в PostgreSQL смена схемы часто тоже очень дешёвая, например добавление поля, переименование (хотя переименование не пробовал) по сути только обновляют метаданные таблицы
Нее. Всегда при смене метаинформации есть эксклюзивная блокировка. Которая может привести к остановке всей работы с таблицей
PD
Andrew Komiagin
Тут ещё вопрос в том как поведёт себя приложение когда в бд в фоне миграция))
Ну, это как раз просто.
Y
Andrew Komiagin
Тут ещё вопрос в том как поведёт себя приложение когда в бд в фоне миграция))
Вообще, я согласен, что мигрировать данные с одной схемы на другую сложно. Но отсутствие схемы эту проблему не решает, а скорее откладывает.