Да, не знал об этой штуке. Спасибо, буду иметь ввиду. Идею SQLFuse можно использовать и для других СУБД, которую не поддерживает Database Project, осталость найти только энтузиастов :)
Речь не идёт о том, какой софт хуже или лучше. Предложен ещё один способ решить проблему версионного контроля SQL-кода, не расходуя дополнительных ресурсов на приобретение специализированного ПО.
Да, если произвести переименование в Git, будет выполнено именно переименование.
Тип модулей определяется исходя из содержимого, например, ограничение DEFAULT выглядить как: CONSTRAINT DEFAULT (getdate()) FOR [dt_done]. SQL Server позволяет создавать функции, хранимые процедуры со ссылками на несуществующие пока объекты, однако, при выполнении, будет выдана ошибка, если они не были созданы.
Синтаксические ошибки — это меньшее из зол, можно редактировать функции и процедуры в IDE, подключившись к серверу, чтобы избежать их -> делать коммит -> заливать на тест. Согласен, спорный момент, но для применения изменений нескольких процедур и полей вполне подойдёт. Но если изменения сложны, то, конечно, необходимо использовать скрипт напрямую в БД. А затем уже закоммитить в репозиторий.
По-моему, самый оптимальный вариант — у каждого разработчика заводить отдельные директории потому, что меньше вероятности возникновения всевозможных коллизий, и у SQLFuse общий кэш для всех сделанных изменений. Можно, конечно, смонтировать БД в общий каталог и использовать SQLFuse для отслеживания изменений и создание коммитов только для истории, но в публикации хотелось рассмотреть вариант, когда изменения накатываются прямо из Git. С помощью описанного подхода можно достаточно быстро разворачивать необходимую структуру для каждого разработчиков. Абстракция здесь такая: одна БД отображается в одну директорию, поэтому, нет, нельзя создавать БД
SQLFuse — это файловая система (на подобие SSHFS, FTPFS и др.), в которой отображаются модули SQL Server. Поэтому, при переименовании директории (которая может быть либо схемой, либо таблицей в абстракции SQLFuse), производится трансляция действия в выполнение процедуры sp_rename. Обратное же отслеживание, то есть из SQL Server, не ведётся, да и не возможно, по сути.
Вы можете сами скачать базу AdventureWorks и потестировать это, проделав шаги, которые описаны в публикации :) Создайте последовательно соответствующие текстовые файлы в нужных директориях (таблицах), настроив заранее таймаут сброса кэша на время, достаточное, чтобы Вы успели это сделать
Конечно же, сначала лучше внести изменения в репозиторий, допустим у себя на локальной машине, затем отправить его в центральный репозиторий, и уже оттуда подтянуть изменения в директорию, где примонтирована БД и настроен Git.
Не обязательно. Можно, например, настроить Linux-сервер, подключаясь к которому (например по SSH), разработчики будут накатывать изменения на БД, либо же коммитить свои изменения при внесении изменений в структуру БД (например, через SSMS) вручную. Принцип тот же, что и с обычными файлами. Также, можно попробовать использовать SSHFS из Windows.
Нет, SQLFuse не производит отслеживание зависимостей от foreign key и т.п., — это остаётся на совести разработчиков.
При всех операциях, в рамках одного сброса кэша, ограничения создаются в последнюю очередь, и при удалении колонок с ограничениями, удаляются в первую очередь.
Да, изменения пропадут, но можно же исправить ошибки и попробовать накатить заново?
Даже в человеческом теле предусмотрены очистители объективов :-) Конечно, марсоход и человек создавались для разных условий и целей, но всё же у природы тоже нет ничего лишнего.
Если говорить о качестве съемки мачтовых камер, то на их объективах пыль тоже садится, но незначительно, и начинает сказываться на изображении только если Curiosity долго стоит на одном месте. Во время движения тряска эффективно очищает стекло.
Разве в NASA не предусмотрели какой-нибудь механизм очистки для объективов, что приходится избавляться от пыли тряской?
Спасибо, за замечание. Текст модулей берётся из вывода хранимой процедуры sp_helptext, либо генерируется из метатаблиц, поэтому врядли удастся столкнуться с этим ограничением.
Разве в NASA не предусмотрели какой-нибудь механизм очистки для объективов, что приходится избавляться от пыли тряской?