FAQ-23-EN: No Collation in columns

Q. There is no Collation on columns. Why?

A. I was involved in developing many different DBs and always had a situation that Collation in a column different from the Database Default was considered as an error. One can avoid it via dbProjector.

 
Discuss →

FAQ-22-EN: Comparing dbProjector and SQL Server Data Tools (SSDT)

A brief list of dbProjector benefits:

  • SSDT does not support working with data tables. Using only a DB schema without reference and/or initialization data (e.g., reports supported by the application, etc.) is not enough in most cases. When deploying a new DB, it is always necessary to develop something extra to fill various directories, etc. dbProjector has developed distribution means not only of the DB schema itself, but also of data that may be contained therein. In addition, flexible tools to add the data in the update are offered.
  • While synchronizing the DB schema to the project in SSDT, one can only select the entire object, for example, one can select the entire table and cannot update only a few columns of the entire table. In dbProjector, one can freely choose to synchronize any parts of the whole object.
  • To work with SSDT, one needs to have a full set of monstrous instruments: MSVS, MSSQLSMS, IIS, etc. on the place where you want to deploy the DB. dbProjector is a small distribution easily to install everywhere .NET. can run. If one needs only to install or update the DB, dbProjector offers a separate tool with no installation required, where one can just click Next as in any normal installer for conventional applications.
  • SSDT – it is Windows only, and only MS SQL Server. dbProjector easily works on Linux and supports both MS SQL Server and PostgreSQL.
  • MS – it is a big bureaucratized machine. If one has something unacceptable in SSDT or wants to add something, you will unlikely influence on it. dbProjector is open to criticism and suggestions

Being formal, let us list some options dbProjector has not:

  • Editing objects from IDE. In IDE dbProjector, one can only change a function or a stored field text. It is assumed that all changes of the objects will be made with a detailed DB copy and then selectively imported to the project.
  • In SSDT, it is possible, for example, to rename a column that will be remembered in some files with the extension “.refactorlog” in XML format. It is a very controversial tool because later on it will be almost impossible to understand what happens in this XML sheet. More easily is, in such cases, to write Pre-Deployment and Post-Deployment scripts by oneself as it is done in dbProjector.

You can write more advantages and disadvantages on dbProjector forum.
 
Discuss →

FAQ-21-EN: When I deploy the PostgreSQL project, user’s grants are rolled up before creating the user itself and deploy transaction is canceled

Q. When I deploy the PostgreSQL project, user’s grants are rolled up before creating the user itself and deploy transaction is canceled, WTF?

A. A short answer: One should create roles; move all grants to the roles. The users must be included in the roles only.

Yes, PG users are simply alias from the role (here one could make a few critical remarks about the PG grant system but let us drop it). However, if used carelessly, one likely rubs the wrong way eventually. It seems to me that it is just a box of dynamite to find in a year of development that I cannot delete some irrelevant users because they have some disjointed grants, or worse, some objects in the DB. It seems to me that a good tool should warn against similar actions.
 
Discuss →

FAQ-23-RU: Нигде на кольюмах нет Collation

Q. На кольюмах нигде нет Collation. Why?

A. Я участвовал в разработке большого количества различных БД. И ни РАЗУ не было такого, чтобы Collation на кольюме отличный от Database Default не являлся ошибкой. Одним способом выстрелить себе в ногу меньше с dbProjector.

Discuss →

FAQ-22-RU: Сравнение dbProjector и SQL Server Data Tools (SSDT)

Краткий список преимуществ dbProjector:

  • SSDT не поддерживает работу с данными таблиц. Одна схема БД без справочных и/или данных для инициализации (например, поддерживаемых приложением типов отчетов и т.д.) – этого явно недостаточно в большинстве случаев. При развертывании новой БД всегда есть необходимость что-то дополнительно придумывать для заливки различных справочников и т.д. dbProjector имеет развитые средства дистрибуции не только самой схемы БД но и данных, которые в ней могут содержаться. Плюс предлагаются гибкие инструменты по дополнению этих данных в апдейтах.
  • При синхронизации схемы БД с проектом в SSDT можно только выбирать только весь объект целиком, например можно взять всю таблицу целиком и нельзя проапдейтить только несколько колонок от всей таблицы например. В dbProjector можно свободно выбирать для синхронизации любые части от целого объекта.
  • Что-бы работать с SSDT вам необходимо на месте где вы хотите развертывать БД иметь весь набор монструозных инструментов: MSVS, MSSQLSMS, IIS и т.д. dbProjector это небольшой дистрибутив, который легко ставиться везде где может работать .NET. Если вам нужно только поставить или обновить БД, то dbProjector предлагает отдельный инструмент, который не требует установки и в котором можно только нажимать Next как в любом нормальном инсталляторе для обычных приложений.
  • SSDT – это только Windows и только MS SQL Server. dbProjector – также легко работает на Linux и поддерживает как MS SQL Server так и PostgreSQL.
  • MS – большая бюрократизированная машина. Если вас что-то не устраивает в SSDT, или хотели-бы какое-то дополнение, вы вряд ли сможете как-то на это повлиять. dbProjector – открыт для критики и пожеланий 🙂

Для порядка перечислим и что есть такого чего нет в dbProjector:

  • Редактирование объектов из IDE. В IDE dbProjector можно только изменить текст функции или хранимки. Предполагается, что все изменения объектов будут производиться с развернутым экземпляром БД и затем выборочно импортироваться в проект.
  • Рефакторинги. В SSDT можно например переименовать колонку и все это будет запоминаться в неких файлах с расширением “.refactorlog” в XML формате. Весьма неоднозначный инструмент т.к. позже из этой простыни XML понять что же будет происходить на самом деле практически нереально. Проще, в таких случаях, самому писать Pre-Deployment и Post-Deployment скрипты как это аналогично сделано и в dbProjector.

Написать еще больше достоинств, а также указать на недостатки вы можете сами на форуме dbProjector.

Discuss →

FAQ-21-RU: Когда я деплою проект PostgreSQL гранты юзера накатываются до создания самого юзера и деплой не проходит

Q. Когда я деплою проект PostgreSQL гранты юзера накатываются до создания самого юзера и деплой не проходит, WTF?

А. Короткий ответ: Завести роли и перевесить все гранты на роли. И юзеров уже включать только в роли.

Да, юзеры в PG это просто алиас от роли (здесь бы можно сказать несколько критических слов в адрес системы грантов PG, но оставим это). Но это как в плюсах, если ими пользоваться неосторожно, то скорой всего рано или поздно наступите на свою же мину. Здесь мне кажется, что обнаружить через год разработки что я не могу удалить каких-то неактуальных юзеров потому что на них висят непонятные разрозненные гранты, или того хуже они прямо владеют какими-то объектами в БД – это просто ящик динамита. Мне кажется хороший инструмент должен предостерегать от таких подобных действий.

Discuss →

FAQ-20-RU: Как сделать чтобы при деплое не удалялись объекты созданные клиентами самостоятельно?

Q. Как сделать чтобы при деплое не удалялись объекты созданные клиентами самостоятельно?

A. Такие объекты нужно добавить в исключения «Project → Project Properties → Ignore». Можно добавлять по маске.

Discuss →