Если вы предпочитаете проектировать БД в текстовом редакторе, то эта программа для вас.
Тут имеется подсветка синтаксиса, многооконный интерфейс, дерево каталогов и файлов файловой системы,
поиск в окне, поиск в каталоге. Работа на данный момент организована со скриптами MS SQL Server и MySQL.
Есть возможность доработать для любого сервера, мне пока понадобились эти два.

Скажете, а зачем еще один редактор SQL, их уже полно. Отвечу, тут есть одна фича, которой я не встречал нигде
и без которой я не представляю себе разработку БД. В некотором виде эта фича появилась в Visual Studio, но она еще далека от идеала.

Так вот, фича заключается в том, что программа позволяет организовать загрузку скрипт в БД одним нажатием кнопки.
При этом скрипт, представляющий собой создание таблиц, вьюх, процедур, функций и триггеров заливается в БД не ломая ее.
При этом БД может быть уже используемой приложением, то есть там уже есть таблицы с пользовательскими данным, есть хранимые процедуры и т.д. Фича данного редактора в том, что он смотрит что есть в БД и модифицирует имеющиеся объекты БД не теряя пользовательские данные.

Например, я веду разработку следующего кода в своем редакторе




загрузил скрипт в БД, написал клиентское приложение и внедрил его. Пользователи активно работают, во всю используют приложение. И тут возникла необходимость добавить поле в таблицу. Добавляю




Нажал кнопку и залил изменения в БД. В таблицу добавилось поле, а хранимые процедуры пересоздались, пользовательские данные остались в таблице. И при этом это всё выполнилось в единой транзакции, что означает, что если при пересоздании таблицы возникла ошибка, то процедуры то не изменятся. И при этом пользователи могут продолжат работать не отключаясь от сервера, если конечно пользовательское приложение не нужно будет обновить.

Кроме того можно компилировать (заливать в БД) не только один файл (не только лишь один файл, но мало кто это может :)
(с) но и папку целиком и даже проект целиком. И это еще не все. В начале каждого файла скрипта можно написать строчку
include=.\Bank.sql
и тогда перед компиляцией файла Company.sql будет выполнена компиляция файла Bank.sql
Словом компиляция я называю заливку скрипта в БД.

Таким образом можно организовать очередность выполнения скриптов/зависимость скриптов друг от друга.

Программа поставляется бесплатно, как есть с целью ее распространения и тестирования. Любые предложения и пожелания приветствуются.

Загрузить SQLEditor

--------------------
Не учи отца и баста!

постоянный мембер,

Также и я сделал, поэтому данный редактор не подойдет для мегабольших БД с огромным числом активных коннекций.
А вот для маленьких и средненьких проектов вещь незаменимая. Вот бы еще к SVN подключить

Dimitry SibiryakovOld Nickпри этом пользователи могут продолжат работать не отключаясь от сервера
И MS SQL позволяет переименовать таблицу и потом её грохнуть не отключая пользователей,
которые с ней уже работают?..


Да, представь себе, позволяет. Может слышал что-нибудь про транзакции и многопользовательский режим работы?

Dimitry SibiryakovOld NickДа, представь себе, позволяет. Может слышал что-нибудь про транзакции и
многопользовательский режим работы?
И что происходит с данными, добавленными в таблицу уже после того, как Ваш редактор её
переименовал и начал переливать данные?


Иди изучай многопользовательский режим работы СУБД, кури мануалы.

ViPRos,

Да, там это есть, но немного не дотягивает.

1. Выстроить очередность скриптов в нужной последовательности нельзя
2. Скрипты обновления таблиц (перезаливки данных) вынесены из транзакции. То есть весь пакет в одной транзакции не сделать, нужно ручками скрипт править
3. Скрипт формируется для конкретной БД по сравнительной схеме, для другой БД нужно заново читать текущую версию и загружать ее в схему XML
4. Это всё есть только для MS SQL Server

У меня пока реализация для MS SQL и для MySQL, но есть возможность сделать и для FireBird и для Oracle и вообще для любой. Надо просто добавить модуль и перекрыть несколько методов. Вот если поступят заявки, то сделаю, а так я добавляю только для себя по мере надобности

ГхостикOld Nickесть возможность сделать и для FireBird и для Oracle и вообще для любой.В курсе что в oracle ddl предложения коммитятся автоматически, и все связанные скажем с дропнутой таблицей процедуры/пакеты инвалидируются?

Не в курсе, я же говорю, что еще не сделал. У MySQL тоже с этим есть проблемы, но чаще всего прокатывает нормально.
Ну что ж, значит будем выкручиваться, что-нибудь придумаем, на то и голова есть.

Похоже никто не понял что это такое. Попробуем на примере. Работал я в одной конторе, там разрабатывали проект на SQL, почти вся логика в БД. Несколько человек работают над одним проектом. У каждого своя копия БД, добавляют таблицы, правят таблицы, переписывают хранимки и т.д. Потом наступаем время Ч и нужно выпустить релиз и тут начинается.

1. Каждый готовит скрипт того, чего он наделал.
2. Собирают скрипты в кучу
3. С рабочей базы снимают бекап, делают копию.
4. Накатывают туда скрипт.
5. Тестируют на ошибки
6. Правят скрипт и тестируют

5 и 6 пункты повторяют до победного.

Чаще всего на подготовку релиза уходило больше времени, чем на разработку логики.

А как у вас?

Dimitry Sibiryakov,

И как он это делает, неизвестно?

alexeyvgOld NickПохоже никто не понял что это такое.
...
Чаще всего на подготовку релиза уходило больше времени, чем на разработку логики.Непонятно, каким образом "это" уменьшает время на подготовку релиза?

Кроме как экономии времени на подготовку первого скрипта, ничего не нахожу.

Лучше использовать не такие причудливые технологии, а старую добрую традицию разработки с использованием средств разработки, с хранением исходников в сорс-контроле, связанными с задачами, тестами и т.д.

Кстати, для маленьких и простых баз MS выпустило чудесное средство, которое тоже само умеет обновлять модель БД. Это даже ещё удобнее, хотя и с ограниченными возможностями.
SQL Server Data Tools (SSDT)

Попробую пояснить. "Это" на подготовку релиза время вообще не тратит. ВООБЩЕ!
То есть, когда начинаете проектировать базу, то просто напросто пишете скрипт для новой базы.
Только CREATE (только хардкор :), никаких ALTER и IF EXISTS.

CREATE TABLE, CREATE VIEW, CREATE TRIGGER, CREATE PROCEDURE, CREATE FUNCTION

Затем нажимаете одну (1) ОДНУ кнопку и база создана.

Теперь Вы внесли изменения в структуру. Для этого нужно просто переписать CREATE TABLE или CREATE PROCEDURE, в зависимости от того, что изменилось. И опять нажимаете ОДНУ кнопку, структура изменилась. И при этом не важно какая это была база. Тестовая, тестовая у коллеги, продакшн или база от другого приложения. Теперь она рабочая и актуальная. Не нужно сравнивать версии, не нужно трястить над пользовательскими данными. Данные не потеряются, версия станет последняя и актуальная.

Всего одна кнопка! Что может быть проще?

И при этом исходники могут лежать в SVN и можно вести многопользовательскую разработку.

Еще раз. В скриптах пишете всегда только CREATE и никогда ALTER. При компиляции никогда не проверяете, что есть в базе.

Кот МатроскинOld NickЕще раз. В скриптах пишете всегда только CREATE и никогда ALTER. При компиляции никогда не проверяете, что есть в базе.

Т.е. из двух скриптов





Оно создаст таблицу (A, B, С)?

Нет, актуальной будет последняя таблица

Кот МатроскинOld Nick,

Т.е. даже в том случае, когда при стандартной технологии с ALTER я не получил бы
вообще никаких проблем - Ваша технология подготовки релиза и Ваш инструмент мне их создаст?

Ну если Вы ТАК работаете с БД, то это Ваши проблемы! Я Вам не завидую :-))))))))))))))

Кот МатроскинOld Nick,

Как "так"? Двум разработчикам понадобилось добавить колонки в одну и ту же таблицу - Вы считаете это невозможным кейсом? А какие тогда кейсы у Вас "на подготовку релиза тратят времени больше, чем на разработку" - расскажите подробней?

Слышали нет, про Source Safe системы?

Один разработчик взял файл для редактирования, залочил его. Добавил колонку. Второй попытался редактировать, а нет, не получается, надо чтобы первый отпустил. Первый закоммитил изменения, теперь второй колонку добавляет. К моей программе это не имеет отношения. Это просто правильная организация труда (разработки)

Кот МатроскинOld Nick,
Мне для кейса "два разработчика хотят добавить колонки к одной таблице" - не нужна SourceSafe система;) Вам (в дополнение к Вашей странной тулзе) - нужна?

Для такого кейса и мозг без надобности

Кот МатроскинOld NickОдин разработчик взял файл для редактирования, залочил его. Добавил колонку. Второй попытался редактировать, а нет, не получается, надо чтобы первый отпустил. Первый закоммитил изменения, теперь второй колонку добавляет
А если бы они оба писали бы Alter table с соответствующей проверкой - им не пришлось бы ничего лочить и никто бы никого не ждал (не говоря уж про то что тулза была бы без надобности). Вас учили, что лишние блокировки (что в работе движка СУБД, что в работе коллектива программистов) - это плохо?

Old NickЭто просто правильная организация труда (разработки)
Нет, это просто низкая квалификация.

То есть Вы хотите сказать, что добавление разными разработчиками в одну таблицу разных полей без уведомления друг друга это высокая квалификация? Разные разработчики надобавляли полей, каждый по своему усмотрению и в результате не таблица, а помойка, что там хранится? Кто-нибудь из команды сможет описать все поля этой таблицы? Или каждый знает только свою часть? И это высокая квалификация? Я в шоке!

Кот МатроскинOld NickТо есть Вы хотите сказать, что добавление разными разработчиками в одну таблицу разных полей без уведомления друг друга это высокая квалификация? Разные разработчики надобавляли полей, каждый по своему усмотрению и в результате не таблица, а помойка, что там хранится? Кто-нибудь из команды сможет описать все поля этой таблицы? Или каждый знает только свою часть? И это высокая квалификация? Я в шоке!

По-моему, Вы запутались ;)
Напоминаю, Вы начали с
. У каждого своя копия БД, добавляют таблицы, правят таблицы, переписывают хранимки и т.д. Потом наступаем время Ч и нужно выпустить релиз и тут начинается.
,
Потом рассказывали что "Да SourceSafe вкупе с моей утилитой на ура такой кейс разрулят!", теперь уже говорите
"Как, разные разработчики работают с одним функционалом? Какой ужас!"

"Во-первых, у меня нет ружья, во-вторых - оно незаряжено" (с)

Что же до вопроса
авторКто-нибудь из команды сможет описать все поля этой таблицы?
- то ответ "Да, разумеется. Причем даже если человек пришел в команду вчера и таблицу не видел до этого в глаза". Вот не далее как на этой неделе я разбирался, с каких пор у нас есть поле и кто и зачем его добавил (как выяснилось, 3 года назад и давно уволившимися людьми). Около 10 минут процесс занял

Называть рабочим беспорядком бардак конечно можно, но это всё равно бардак.
И да, я не запутался. Я описал как не надо работать. Именно после такого опыта я и решился написать свою программу.