Наверное, каждый разработчик сталкивался с базами SQLite хотя бы раз за свою карьеру. А если он занят мобильными приложениями, то, видимо, просто не имеет шанса их избежать. Мы тоже не стали исключением и в своих проектах часто используем эту замечательную БД. Как известно, создателями SQLite для администрирования официально предоставляется лишь консоль. Это породило целый сонм чудовищ громадье различных менеджеров от сторонних компаний.
Увы, количество не перешло в качество. У всех приложений мы нашли те или иные проблемы. Некоторые слегка шокируют. Например, очень популярным менеджером является бесплатный add-on браузера Firefox с незатейливым названием SQLite Manager. 234 записи в его issue tracker (как это будет по-русски?) пошатнут веру в будущее даже у бывалого айтишника. «Неверное отображение 8-байтных чисел». Да, совершенно верно, этот менеджер не может правильно показать все цифры в представлении 8-байтного целого (видимо из-за своей javascript натуры). Подумаешь, кого волнуют большие числа?
Многие менеджеры являются универсальными (поддерживают все популярные БД) и просто не дают использовать все особенности SQLite (которых весьма много). Еще одна проблема: перегруженный интерфейс. Часто возникало ощущение, что разработчики просто «вывалили» весь функционал приложения на главный экран в виде кучи мелких кнопочек. Также раздражало разбиение возможностей по нескольким приложениям: редактор данных, редактор схемы, импортер данных и пр. Маркетинг — это хорошо, но неудобно пользоваться. Наконец, модное нынче поветрие — выпускать приложение сразу на нескольких платформах с единой кодовой базой и фреймворком — часто приводит к появлению кучи мелких багов в интерфейсе: проблемы со шрифтами, неверная кодировка, неправильная высота строк, «уезжание» контролов и пр.
Наши сомнения подкрепил один пост на stackoverflow.com, в котором делался вывод, что «несмотря на большое число менеджеров баз SQLite, действительно удобного не существует и это играет отрицательную роль в плане популяризации SQLite». Так этот проект и появился на свет.
Разрешите представить: SqliteDog — современный менеджер баз данных SQLite. Нам хотелось немного изменить привычный интерфейс редактора БД, чтобы он больше походил на «помесь Excel с Chrome», чем на «SQL Server Management Studio». Мы исходили из следующей мантры: менеджер БД стоит на «трех китах». Это сами данные, схема данных и SQL запросы. Следует сделать выборку данных максимально простой и удобной, следует отображать данные максимально полезно (см. ниже). Следует показать схему данных наглядно и позволить ее произвольно менять. Редактор SQL должен быть красивым, удобным; работа с SQL не должна создавать проблем. Также хотелось иметь наглядный и удобный механизм управления настройками (PRAGMA) SQLite, которых много и которые на очень многое влияют. Например, по умолчанию ограничения внешних ключей отключены и размер кэша составляет 2000 страниц базы. В 95% случаев это не лучшие настройки, но они обычно «спрятаны» внутри каких-то подменю.
Итак, мы начали анализировать имеющиеся приложения, собирать идеи и пожелания. И этот этап занял где-то 3 месяца. Основное понимание было таким: почти все редакторы БД построены на архаичных интерфейсных решениях, которые они копируют друг у друга. Приведем несколько примеров.
Это такойпыточный контрол, который обычно находится слева и содержит в себе связанные в деревья соединения к БД и объекты БД. Чтобы добраться до, например, столбцов таблицы обычно нужно:
— развернуть список БД и найти нужную;
— развернуть ветку «Таблицы»;
— найти нужную таблицу;
— развернуть ветку «Столбцы».
Причем сама операция «разворачивания» означает:
— попадание мышкой в малюсенький крестик, который каждый раз меняет свое положение;
— появление нового списка, который нужно осмотреть и который сдвигает уже имеющееся представление дерева.
Если подумать, то дерево — это, наверное, самый неудобный контрол из возможных; его используют из-за гибкости (любую иерархию можно засунуть). Однако, сценарий работы с БД, как правило, более сложный, чем просто «посмотреть столбцы». Допустим, пользователь хочет понять — нет ли у столбца какого-то ограничения. Как в этом случае нам поможет список столбцов? Никак, потому что ограничение на столбец может быть задано на уровне таблицы. А если пользователь ищет какой-то конкретный столбец в нескольких таблицах? Ему намного удобнее открыть схему БД, где на одном экране будет сразу все необходимое (чем разворачивать каждую таблицу). И т.д.
Кроме того, нам не нравилась (привычная) практика работы с несколькими базами данных в одном экземпляре приложения. Нам показалось, что это источник путаницы и усложнения: все время нужно понимать в какой базе ты проводишь то или иное действие. Мы решили, что один экземпляр приложение работает ровно с одной БД (одно соединение) и отказались от дерева в пользу линейного списка таблиц и представлений. Можно быстро переключиться на любую базу из истории. В итоге, чтобы посмотреть и отредактировать схему таблицы в SqliteDog нужно сделать всего два клика. При этом элементы списка объектов БД, разумеется, не сдвигаются, а остаются на своих местах.
Как это часто бывает, одно решение повлекло за собой другое. Как только мы решили, что хотим быстро переключаться между базами, сбрасывая все текущее состояние, возникла проблема потери введенных SQL запросов. Хранить SQL запросы в файлах? Но зачем? Опять — архаизм. У нас «под рукой» мощнейшая СУБД. Размеры запросов, как правило, невелики. Вести их историю не составит никаких проблем. Итак, все запросы автоматом сохраняем в специальной БД. Ушло это назойливое окно «Вы сделали изменения, хотите сохранить?», какое облегчение. Но что-то и потерялось. Имена файлов несут какую-то информацию, привязку, а теперь их нет вовсе. Решили эту проблему, сделав поиск в истории по ключевым словам запроса.
Все менеджеры БД позволяют вывести в таблицу запрошенные данные (этого у них не отнять). Как они это делают? Например, ширина столбцов. Обычно вместо подгонки под содержимое используется просто равномерное деление всей ширины на количество столбцов. Это крайне нерационально использует экранное пространство. Или взять представление данных. Отчего сразу не показать цветом какого типа значение: строка или число? Отчего число сразу не отбить вправо? Пустая ячейка — это NULL или пустая строка? Чтобы это узнать, нужно еще кликать по ячейке и смотреть какие-то свойства, почему? Если в ячейке находится BLOB (двоичные данные) — зачем мне видеть его шестнадцатеричное представление? Какой резон? Заметим, что все менеджеры гордо хвастаются показом картинок в BLOB-ах. Спасибо, конечно, но строки и числа все-таки используются чаще. Встречается еще и такой (довольно странный) прием. Если значение столбца представляет из себя строку с переводами кареток, то высота строки таблицы увеличивается пропорционально количеству строк. То бишь, допустим, у вас в столбце хранятся небольшие XML тексты. При просмотре на один экран теперь влезают максимум 3 записи.
В SqliteDog мы постарались «выжать максимум» полезного при отображении данных. Сразу, без дополнительных настроек. Числовые значения подсвечены цветом и отбиты вправо. Значение NULL отображается особо и легко отличимо от пустой строки. Для BLOB показан размер. Если в строке-значении есть управляющие символы ("\r\n"), они подсвечены другим цветом, высота строки таблицы не увеличивается. Картинки, разумеется, тоже отображаются. И одним кликом можно посмотреть картинку на весь экран. По клику (или нажатию F4) ширина столбцов видимых строк равномерно подгоняется под их содержимое. Двойной клик на ячейке подгоняет ширину конкретного столбца. Скроллить по таблице можно и мышкой, и клавиатурой. Причем прокрутка колеса мыши при зажатой клавишей Control позволяет прокручивать таблицу влево-вправо. Все эти мелочи облегчают жизнь.
Традиционно, многие приложения имеют состояние «нет документа». Например, при старте. А нужно ли это пользователю? Предположим пользователь SqliteDog закрывает соединение к базе. Что это значит? Он хочет открыть другую БД? Но зачем закрывать текущую — просто открой другую. Он хочет завершить работу? Но тогда нужно просто закрыть приложение. Решение было найдено такое: соединение к БД в SqliteDog есть всегда. Если пользователь закрыл БД, то SqliteDog создает пустую БД «в памяти» (одна из полезнейших возможностей SQLite). То же и при запуске приложения. Как только эта фича появилась, тут же возник дополнительный сценарий использования. Иногда нужно быстро вспомнить название функции SQLite. Запускаем SqliteDog, сразу доступно окно ввода SQL. Начинаем набирать название — выпадает список автодополнения. Находим нужную функцию, копируем, готово.
По мере разработки становилось ясно, что, потенциально, количество функционала — безгранично. Такова природа проекта. Всегда можно найти еще одну «хотелку». И решить, что без нее — ну, никак. Поэтому было принято «бритвенное» решение: часть «больших» фич уходит во «вторую версию». Решение по фичам принималось коллективно. Таким образом, ведется список активных задач с приоритетами и список фич «второй версии». Видеть их вместе удобно, чтобы снова и снова не придумывать одно и то же. Бывало так, что заготовки для одной возможности позволяли легко реализовать другую и тогда фича «возвращалась» из второй версии в первую. Также из забавных моментов: некоторые фичи так долго откладывались, заменяясь более срочными, что в итоге в SqliteDog нельзя перетаскивать вкладки мышкой. Это будет исправлено во «второй версии» (наверное :). Еще один компромисс — это выбор одной платформы (Windows). Увы, мы не смогли найти приемлимого для нас фреймворка, который обеспечил бы кроссплатформенность без потери качества и скорости. Делать свой, то есть изобретать велосипед — это все-таки перебор, цель изначально стояла иная. В итоге проект был «заточен» под Windows (и отнял примерно год). Но мы получили отзывчивость и качество отображения на требуемом уровне.
Засим остановимся (но, если хабрасообщество заинтересовано в продолжении «саги», то оно последует). Что касается лицензии на продукт. Мы решили, что помимо коммерческой будет доступна официальная бесплатная версия SqliteDog. Без лимитов по времени, количеству строк, количеству таблиц, размеру БД и пр. В бесплатной версии после 30 дней использования становятся недоступны только дизайнеры (базы, таблицы и индекса) и некоторый импорт/экспорт данных. Интерфейс SqliteDog полностью русифицирован (разумеется, есть и английская трансляция для любителей). Русскоязычная версия сайта также сушествует.
http://sqlitedog.com
SqliteDog — это менеджер БД SQLite для эффективной работы. Его создатели решили отказаться от привычных интерфейсных решений и максимально упростить и облегчить взаимодействие. Поэтому одно приложение = одна база (точнее, одно соединение, можно сделать ATTACH других баз). Данные выборок отображаются максимально информативно, просматривать/сортировать и даже редактировать записи можно в процессе выполнения запроса (остановить загрузку можно в любой момент, нажав Esc). Некоторые возможности SqliteDog являются уникальными. Например, управление транзакцией через кнопки на панели соединения. Или режим мониторинга таблицы, при котором новые записи автоматически подгружаются («Выбрать последние 1000», нажать кнопку со стрелкой в кружке). Или возможность открыть схему базы и зафиксировать ее в отдельном окне на втором мониторе (чтобы всегда иметь перед глазами). Или возможность одним нажатием перевести переводы кареток в значении столбца из UNIX в Windows формат.
Мы будем рады услышать отзывы и пожелания по доработке. Спасибо за интерес.
Увы, количество не перешло в качество. У всех приложений мы нашли те или иные проблемы. Некоторые слегка шокируют. Например, очень популярным менеджером является бесплатный add-on браузера Firefox с незатейливым названием SQLite Manager. 234 записи в его issue tracker (как это будет по-русски?) пошатнут веру в будущее даже у бывалого айтишника. «Неверное отображение 8-байтных чисел». Да, совершенно верно, этот менеджер не может правильно показать все цифры в представлении 8-байтного целого (видимо из-за своей javascript натуры). Подумаешь, кого волнуют большие числа?
Многие менеджеры являются универсальными (поддерживают все популярные БД) и просто не дают использовать все особенности SQLite (которых весьма много). Еще одна проблема: перегруженный интерфейс. Часто возникало ощущение, что разработчики просто «вывалили» весь функционал приложения на главный экран в виде кучи мелких кнопочек. Также раздражало разбиение возможностей по нескольким приложениям: редактор данных, редактор схемы, импортер данных и пр. Маркетинг — это хорошо, но неудобно пользоваться. Наконец, модное нынче поветрие — выпускать приложение сразу на нескольких платформах с единой кодовой базой и фреймворком — часто приводит к появлению кучи мелких багов в интерфейсе: проблемы со шрифтами, неверная кодировка, неправильная высота строк, «уезжание» контролов и пр.
Наши сомнения подкрепил один пост на stackoverflow.com, в котором делался вывод, что «несмотря на большое число менеджеров баз SQLite, действительно удобного не существует и это играет отрицательную роль в плане популяризации SQLite». Так этот проект и появился на свет.
Разрешите представить: SqliteDog — современный менеджер баз данных SQLite. Нам хотелось немного изменить привычный интерфейс редактора БД, чтобы он больше походил на «помесь Excel с Chrome», чем на «SQL Server Management Studio». Мы исходили из следующей мантры: менеджер БД стоит на «трех китах». Это сами данные, схема данных и SQL запросы. Следует сделать выборку данных максимально простой и удобной, следует отображать данные максимально полезно (см. ниже). Следует показать схему данных наглядно и позволить ее произвольно менять. Редактор SQL должен быть красивым, удобным; работа с SQL не должна создавать проблем. Также хотелось иметь наглядный и удобный механизм управления настройками (PRAGMA) SQLite, которых много и которые на очень многое влияют. Например, по умолчанию ограничения внешних ключей отключены и размер кэша составляет 2000 страниц базы. В 95% случаев это не лучшие настройки, но они обычно «спрятаны» внутри каких-то подменю.
Итак, мы начали анализировать имеющиеся приложения, собирать идеи и пожелания. И этот этап занял где-то 3 месяца. Основное понимание было таким: почти все редакторы БД построены на архаичных интерфейсных решениях, которые они копируют друг у друга. Приведем несколько примеров.
Дерево объектов БД
Это такой
— развернуть список БД и найти нужную;
— развернуть ветку «Таблицы»;
— найти нужную таблицу;
— развернуть ветку «Столбцы».
Причем сама операция «разворачивания» означает:
— попадание мышкой в малюсенький крестик, который каждый раз меняет свое положение;
— появление нового списка, который нужно осмотреть и который сдвигает уже имеющееся представление дерева.
Если подумать, то дерево — это, наверное, самый неудобный контрол из возможных; его используют из-за гибкости (любую иерархию можно засунуть). Однако, сценарий работы с БД, как правило, более сложный, чем просто «посмотреть столбцы». Допустим, пользователь хочет понять — нет ли у столбца какого-то ограничения. Как в этом случае нам поможет список столбцов? Никак, потому что ограничение на столбец может быть задано на уровне таблицы. А если пользователь ищет какой-то конкретный столбец в нескольких таблицах? Ему намного удобнее открыть схему БД, где на одном экране будет сразу все необходимое (чем разворачивать каждую таблицу). И т.д.
Кроме того, нам не нравилась (привычная) практика работы с несколькими базами данных в одном экземпляре приложения. Нам показалось, что это источник путаницы и усложнения: все время нужно понимать в какой базе ты проводишь то или иное действие. Мы решили, что один экземпляр приложение работает ровно с одной БД (одно соединение) и отказались от дерева в пользу линейного списка таблиц и представлений. Можно быстро переключиться на любую базу из истории. В итоге, чтобы посмотреть и отредактировать схему таблицы в SqliteDog нужно сделать всего два клика. При этом элементы списка объектов БД, разумеется, не сдвигаются, а остаются на своих местах.
Сохранение SQL запросов
Как это часто бывает, одно решение повлекло за собой другое. Как только мы решили, что хотим быстро переключаться между базами, сбрасывая все текущее состояние, возникла проблема потери введенных SQL запросов. Хранить SQL запросы в файлах? Но зачем? Опять — архаизм. У нас «под рукой» мощнейшая СУБД. Размеры запросов, как правило, невелики. Вести их историю не составит никаких проблем. Итак, все запросы автоматом сохраняем в специальной БД. Ушло это назойливое окно «Вы сделали изменения, хотите сохранить?», какое облегчение. Но что-то и потерялось. Имена файлов несут какую-то информацию, привязку, а теперь их нет вовсе. Решили эту проблему, сделав поиск в истории по ключевым словам запроса.
Просмотр выбранных данных в таблице
Все менеджеры БД позволяют вывести в таблицу запрошенные данные (этого у них не отнять). Как они это делают? Например, ширина столбцов. Обычно вместо подгонки под содержимое используется просто равномерное деление всей ширины на количество столбцов. Это крайне нерационально использует экранное пространство. Или взять представление данных. Отчего сразу не показать цветом какого типа значение: строка или число? Отчего число сразу не отбить вправо? Пустая ячейка — это NULL или пустая строка? Чтобы это узнать, нужно еще кликать по ячейке и смотреть какие-то свойства, почему? Если в ячейке находится BLOB (двоичные данные) — зачем мне видеть его шестнадцатеричное представление? Какой резон? Заметим, что все менеджеры гордо хвастаются показом картинок в BLOB-ах. Спасибо, конечно, но строки и числа все-таки используются чаще. Встречается еще и такой (довольно странный) прием. Если значение столбца представляет из себя строку с переводами кареток, то высота строки таблицы увеличивается пропорционально количеству строк. То бишь, допустим, у вас в столбце хранятся небольшие XML тексты. При просмотре на один экран теперь влезают максимум 3 записи.
В SqliteDog мы постарались «выжать максимум» полезного при отображении данных. Сразу, без дополнительных настроек. Числовые значения подсвечены цветом и отбиты вправо. Значение NULL отображается особо и легко отличимо от пустой строки. Для BLOB показан размер. Если в строке-значении есть управляющие символы ("\r\n"), они подсвечены другим цветом, высота строки таблицы не увеличивается. Картинки, разумеется, тоже отображаются. И одним кликом можно посмотреть картинку на весь экран. По клику (или нажатию F4) ширина столбцов видимых строк равномерно подгоняется под их содержимое. Двойной клик на ячейке подгоняет ширину конкретного столбца. Скроллить по таблице можно и мышкой, и клавиатурой. Причем прокрутка колеса мыши при зажатой клавишей Control позволяет прокручивать таблицу влево-вправо. Все эти мелочи облегчают жизнь.
Что такое «ничего»?
Традиционно, многие приложения имеют состояние «нет документа». Например, при старте. А нужно ли это пользователю? Предположим пользователь SqliteDog закрывает соединение к базе. Что это значит? Он хочет открыть другую БД? Но зачем закрывать текущую — просто открой другую. Он хочет завершить работу? Но тогда нужно просто закрыть приложение. Решение было найдено такое: соединение к БД в SqliteDog есть всегда. Если пользователь закрыл БД, то SqliteDog создает пустую БД «в памяти» (одна из полезнейших возможностей SQLite). То же и при запуске приложения. Как только эта фича появилась, тут же возник дополнительный сценарий использования. Иногда нужно быстро вспомнить название функции SQLite. Запускаем SqliteDog, сразу доступно окно ввода SQL. Начинаем набирать название — выпадает список автодополнения. Находим нужную функцию, копируем, готово.
Компромиссисы Компромиссы
По мере разработки становилось ясно, что, потенциально, количество функционала — безгранично. Такова природа проекта. Всегда можно найти еще одну «хотелку». И решить, что без нее — ну, никак. Поэтому было принято «бритвенное» решение: часть «больших» фич уходит во «вторую версию». Решение по фичам принималось коллективно. Таким образом, ведется список активных задач с приоритетами и список фич «второй версии». Видеть их вместе удобно, чтобы снова и снова не придумывать одно и то же. Бывало так, что заготовки для одной возможности позволяли легко реализовать другую и тогда фича «возвращалась» из второй версии в первую. Также из забавных моментов: некоторые фичи так долго откладывались, заменяясь более срочными, что в итоге в SqliteDog нельзя перетаскивать вкладки мышкой. Это будет исправлено во «второй версии» (наверное :). Еще один компромисс — это выбор одной платформы (Windows). Увы, мы не смогли найти приемлимого для нас фреймворка, который обеспечил бы кроссплатформенность без потери качества и скорости. Делать свой, то есть изобретать велосипед — это все-таки перебор, цель изначально стояла иная. В итоге проект был «заточен» под Windows (и отнял примерно год). Но мы получили отзывчивость и качество отображения на требуемом уровне.
Лицензия
Засим остановимся (но, если хабрасообщество заинтересовано в продолжении «саги», то оно последует). Что касается лицензии на продукт. Мы решили, что помимо коммерческой будет доступна официальная бесплатная версия SqliteDog. Без лимитов по времени, количеству строк, количеству таблиц, размеру БД и пр. В бесплатной версии после 30 дней использования становятся недоступны только дизайнеры (базы, таблицы и индекса) и некоторый импорт/экспорт данных. Интерфейс SqliteDog полностью русифицирован (разумеется, есть и английская трансляция для любителей). Русскоязычная версия сайта также сушествует.
http://sqlitedog.com
Заключение или TL;DR
SqliteDog — это менеджер БД SQLite для эффективной работы. Его создатели решили отказаться от привычных интерфейсных решений и максимально упростить и облегчить взаимодействие. Поэтому одно приложение = одна база (точнее, одно соединение, можно сделать ATTACH других баз). Данные выборок отображаются максимально информативно, просматривать/сортировать и даже редактировать записи можно в процессе выполнения запроса (остановить загрузку можно в любой момент, нажав Esc). Некоторые возможности SqliteDog являются уникальными. Например, управление транзакцией через кнопки на панели соединения. Или режим мониторинга таблицы, при котором новые записи автоматически подгружаются («Выбрать последние 1000», нажать кнопку со стрелкой в кружке). Или возможность открыть схему базы и зафиксировать ее в отдельном окне на втором мониторе (чтобы всегда иметь перед глазами). Или возможность одним нажатием перевести переводы кареток в значении столбца из UNIX в Windows формат.
Мы будем рады услышать отзывы и пожелания по доработке. Спасибо за интерес.
