Я намагався здійснити пошук цього питання при переповненні стека, але не міг знайти жодного запитання для цього.
Я новачок Liquibaseі хочу знати
Liquibase?Liquibaseв проекті?Я знаю, що це дозволяє зберегти всі зміни бази даних в одному місці, але подібне можна зробити, створивши прості SQLфайли в якійсь системі сховищ і постійно оновлюючи їх з часом.
Відповіді:
Ключовим відмінником між самокерованим файлом створення схеми та Liquibase (або іншими інструментами міграції схеми ) є те, що останній надає журнал змін схеми. Це запис змін схеми з часом. Це дозволяє конструктору баз даних вказувати зміни в схемі та дозволяє програмне оновлення або зниження версії схеми на вимогу.
Є й інші переваги, такі як:
Одним з альтернативних інструментів є маховий шлях .
Ви вибрали б використовувати інструмент міграції схем, коли ви хочете або вам потрібно автоматично керувати оновленнями схеми без втрати даних. Тобто, ви очікуєте, що схема зміниться після того, як ваша система буде розгорнута в середовищі, що довго живе, наприклад, на сайті клієнта або стабільному тестовому середовищі.
Я бачив, як liquibase створює дисципліну серед розробників, коли йдеться про зміну схеми. Ви просто не можете піти і перезаписати зміни та виконати інші розробники. Натомість ви створюєте власний набір змін і додаєте його в кінець послідовності змін, які потрібно виконати. Це також вносить ясність щодо того, які зміни відбулися коли і хто їх вніс.
Дуже "версійний" підхід до підтримки схеми.
Для початківців це створює враження "непотрібної роботи".
Якщо у вас є кілька екземплярів баз даних у dev, qa, виробництві, і ви хочете мати інструмент для автоматичного відстеження історії змін та інтелектуального застосування змін (застосувати різницю поточної схеми та кінцевої схеми), такі інструменти, як liquibase або flyway, будуть дуже корисними .
Я вважаю, що Liquibase чудова, коли ваша філософія полягає в тому, що база даних - це додаткова думка. Ця філософія спричинила більшість поганих баз даних у виробництві - і більшість із них є поганими. База даних повинна бути розроблена з повним оглядом усієї бізнес-системи, а не розробниками додатків, кожен з яких працює у своїх власних силосах. Останній метод призводить до робочих процесів, денормалізованих даних, поганих взаємозв’язків між таблицями, дублювання бізнес-сфер та загальної безладної системи з високими витратами на обслуговування, яку клієнт ненавидітиме незабаром після розгортання через проблеми, які він спричиняє. Якщо база даних розроблена для ТОЧНОГО відображення ділових відносин, її тривалість життя буде в 5 разів довшою і буде служити своїй меті в 5 разів кращою, ніж та, розроблена поштучно, як це, на жаль, є більшість.
Liquibase сам по собі не є проблемою, але він дає змогу розробникам програм розробляти базу даних. У цьому проблема.
Я думаю, чому на liquibase можна відповісти, якщо ви пройдете статтю нижче http://shengwangi.blogspot.com/2016/04/liquibase-helloworld-example.html
Якщо ви уважно прочитаєте, дуже корисною є можливість переходу на нижчу версію з вищої версії за допомогою простих команд mvn або CLI, якої ви не отримаєте, якщо пройдете підхід до введення вашого файлу sql у GIT, тому що тоді ви доведеться вручну запускати ці сценарії, а також у вас немає змін, таких як: - хто вніс зміни та ін.
Будучи людиною моєї команди DevOps, я хотів би мати всі свої файли SQL в одному місці, тобто в моєму SCM (управління вихідним кодом)
Також під час фази CI / CD, якщо схема DB створюється разом із нею, це економить багато часу та ресурсів. Вам не доведеться мати іншу особу, яка керує вашою базою даних для цього клієнта.
ORM, такі як Flyway, Liquibase, EF тощо допомагає досягти цього.