Pull to refresh

Comments 22

Открывать порты и управлять базами, подключаясь с другого сервера или со своего рабочего компьютера — это и неудобно и есть соображения безопасности
А открывать web-морду безопасно? И да, мне вот удобнее подключиться десктопным клиентом. Интерфейс отзывчивее и возможностей больше. Так что это субъективно.
А так, молодцы, начинание хорошее.
Открыть веб-морду безопасно, если есть SSL-шифрование трафика и аутентифиуация, что мы и реализовали.
так же безопасно соединиться с десктопного клиента по ssh-тоннелю
вот вот, Valentina и Robomongo ни на что не променяю :) Хотя и для веб интерфейса есть ситуации, когда его использование оправдано.
Вообще хочется допилить веб-интерфейс до такого состояния, что он будет доступен обычному пользователю. Для этого нужно только ввести права доступа к разным данным с настройкой этих прав админом и подстановка в WHERE условий ID пользователя из сессии, если нужно ему отфильтровать его данные. Ну и убрать панель с SQL-запросами. Это будет куда удобнее, чем пользователи, ходившие в phpMyAdmin, напуганные программистами, что они могут все уничтожить и делающие там по 2 клика в минуту трясущимися руками, вычитывая в ужасе все что есть на экране. Я такое наблюдал в нескольких проектах, и это, к сожалению, не редкость.
Честно говоря не совсем понимаю зачем пользователям вообще знать о phpMyAdmin и что им там делать :)
Для них-то админки и создаются.
Это понятно, но случаи такие были зафиксированы, похоже, программисты этих проектов были совсем не гуманистами )
Не планируется, это не типичный выбор для ноды. Напиши сам, Андрюха, сделай Майкрософту приятно.
Андрюха, ты шо, обиделся? Там делов то на 2 часа, основные SELECT, UPDATE, DELETE, ALTER и т.д. выражения же не сильно отличаются, так что, добавить поддержку любой SQL-ной СУБД не сложно. Вот добавить туда другие NoSQL базы будет посложнее (CouchDB, memcached, Redis хотелось бы реализовать).
А вот зачем, из-за простоты своей реализации — это хорошая основа для разработки кастомных интерфейсов по управлению базами данных. Кастомизировать такой редактор — дело одного дня и я сам уже для нескольких проектов быстро поднял админки на его основе, убрав вывод SQL и ограничив доступ. И теперь ими пользуются люди, ничего не смыслящие в ssh и не имеющие развернутого локально софта по управлению БД. Все универсальные средствам для управления БД, что мне попадались, для этого не годятся.
Вы допускаете людей не смыслящих в ssh до управления БД?
Люди, для которых эта БД является рабочим инструментом автоматизации их бизнеса, вполне в состоянии наполнить справочники, вручную задать параметры объектов, сделать выборки, которых не предусматривает фронт-энд интерфейс, найти и исправить данные, которые недоступны из фронт-энда. Так же есть постановщики заданий, специалисты по моделированию предметной области, они не обязаны знать что такое ssh, и часто не знают этого.
Иными словами система позволяет вносить изменения в уровень БД, минуя уровень приложения, а следовательно создавать инвалидные данные или уничтожать их, если не понравилось. Здорово!
Для специалистов и сотрудников, имеющих квалификацию и понимание структуры базы, но не занимающихся разработкой, это великое счастье. Кроме того, контроль целостности данных может выполняться как на уровне приложения, так и на уровне БД, это уже на выбор архитектора. Да и миновать уровень приложения часто необходимо.
У нас очень разные взгляды в этом вопросе, я бы сказал диаметрально противоположные.
Я против перескакивания уровня приложения, это может нарушить счетчики, актуализацию кеша, целостность деревьев, управление состоянием объектов, валидацию данных итпитпитп
Я против неуправляемого приложением контроля целостности данных, т.к. это вызывает необходимость дополнительной обработки исключений на уровне приложения, а двойную работу делать как-то лень в частности и не ДРАЙно в общем.
Великое счастье разработчика, для меня в квалифицированных сотрудниках способных сформулировать тз достаточное для управления информационной системой в целом, а не базы данных в частности. За последние 3 года в базу непосредственно лазил ну с 10-к раз, за последние 2 года, только при сбоях. Конечно не считая случаев настройки первичных прав.
А сверстать формочку или отчетик клиенту при грамотно спроектированном приложении часто занимает минуты. Это однозначно быстрее и лучше, чем сотрудники каким-нибудь БДадмином и своими шаловливыми руками будут перескакивать через уровень приложения, ломая все мыслимые и немыслимые связи. Привет дебаг!
Да, сомнительная вещь как мне кажется. ssh -L 2345:localhost:5432 my-db-server и pgadmin — делов всего ничего
По моему интересная идея, главное допилить ее до готовности :)
Тогда можно будет судить, насколько она востребована.

А как реализован вывод логов sql запроса в logs?
Стараемся, со времени этой публикации, уже существенно улучшили.
Для вывода логов же, сделали так: с клиента происходит вызов AJAX API, на сервере написали обертку вокруг драйверов, которая делает запись в логи на сервере, замеряет время выполнения и логает медленные запросы, ну и возвращает сгенерированные запросы в AJAX API, которое возвращает SQL, результат и сообщения об ощибках на клиент.
Полезная публикация. Побольше бы таких.
Sign up to leave a comment.

Articles