Задача:
Выгрузить часть данных из MS SQL в отдельный файлик и положить его на удалённый Linux\Windows хост с возможностью последующего обновления посредством SQL-запросов (Insert, Update, Delete).
Что подходит:
Заливка, установка и запуск на хосте службы/демона/процесса, который будет принимать входящие соединения и устанавливать персистентное соединение, принимая команды и отдавая данные из этой базы-файла. Достаточно одного соединения, параллелинг не обязателен (хотя и желателен). Наличие транзакций. Хорошая производительность. Клиент на Windows.
Что не подходит:
Любые No-SQL базы и кастомные решения. Решения под лицензией GPL.
Буду рад любым советам по теме.
В настоящий момент наиболее адекватным видится использование Firebird. Найдена какая-то странная штука www.sqlitening.com, возможно кто-нибудь пользовался и может рассказать про то, насколько оно юзабильно (пугает PowerBASIC o.o).
Здравствуйте, LWhisper, Вы писали:
LW>Всем привет!
LW>Задача: LW>Выгрузить часть данных из MS SQL в отдельный файлик и положить его на удалённый Linux\Windows хост с возможностью последующего обновления посредством SQL-запросов (Insert, Update, Delete).
LW>Что подходит: LW>Заливка, установка и запуск на хосте службы/демона/процесса, который будет принимать входящие соединения и устанавливать персистентное соединение, принимая команды и отдавая данные из этой базы-файла. Достаточно одного соединения, параллелинг не обязателен (хотя и желателен). Наличие транзакций. Хорошая производительность. Клиент на Windows.
LW>Что не подходит: LW>Любые No-SQL базы и кастомные решения. Решения под лицензией GPL.
LW>Буду рад любым советам по теме. LW>В настоящий момент наиболее адекватным видится использование Firebird. Найдена какая-то странная штука www.sqlitening.com, возможно кто-нибудь пользовался и может рассказать про то, насколько оно юзабильно (пугает PowerBASIC o.o).
LW>Спасибо за внимание.
Изложенные требования — это явно не просто файлик.
А чем не устраивает поднять еще один ms sql? FB — это тоже субд, разве что может работать под linux.
Здравствуйте, LWhisper, Вы писали:
LW> Буду рад любым советам по теме. LW> В настоящий момент наиболее адекватным видится использование Firebird.
Firebird, Мускул/Мария, Postgre, что угодно. Выбирай то, что лучше знаешь (я так понял, что NoSQL ты поэтому отмел). Ну и по лицензиям смотри, у многих есть dual licensing.
Но SQL гонять через интернет не советую, хлебнешь лиха. Делаешь простейший REST API, и выбор становится намного шире, а жизнь комфортнее.
Здравствуйте, wildwind, Вы писали:
W>Но SQL гонять через интернет не советую, хлебнешь лиха. Делаешь простейший REST API, и выбор становится намного шире, а жизнь комфортнее.
Здравствуйте, Слава, Вы писали:
С> W>Но SQL гонять через интернет не советую, хлебнешь лиха. Делаешь простейший REST API, и выбор становится намного шире, а жизнь комфортнее.
С> Какого именно лиха?
В основном лихо кроется в том, что SQL это stateful протокол. К примеру, нужно отслеживать обрыв коннекта и уметь на него реагировать.
Кроме того, для распределенной системы это низкий уровень абстракции. Если все взаимодействие между частями сводится к периодической репликации, то закладывание в одну часть знаний о внутренностях другой части излишне и невыгодно. К примеру, если через какое-то время ТС обнаружит, что выбранная СУБД его не устраивает и захочет ее заменить, то переделывать придется обе части.
Здравствуйте, wildwind, Вы писали:
W>К примеру, если через какое-то время ТС обнаружит, что выбранная СУБД его не устраивает и захочет ее заменить, то переделывать придется обе части.
В этом случае стоит сразу брать постгрес и не выдумывать.
Здравствуйте, Alex.Che, Вы писали:
>> В этом случае стоит сразу брать постгрес и не выдумывать.
AC>из-за почему?
Если речь о бесплатных базах, то круче постгреса нет ничего. По потреблению ресурсов он масштабируется и вверх, и вниз. Какой смысл брать что-то маломощное, sqlite какой-то, сеть к нему прикручивать, если можно сразу использовать полноценную СУБД?
Здравствуйте, Alex.Che, Вы писали:
>> Если речь о бесплатных базах, то круче постгреса нет ничего.
AC>чем армяне! (с)
Не понял вас. Широко используемых баз не столь много. Есть мыскль, любмый из за синдрома утенка и LAMP. Есть firebird, ужас, любимый на территории exUSSR разного рода разработчиками на delphi. Есть sqlite, часто используемый как embedded база, к которой обращается ровно одно приложение. Наконец, есть постгрес, который быстрее мыскля и богаче его возможностями.
Если сравнивать постгрес с MsSql и Ораклом — разумеется, он проигрывает.
Здравствуйте, BlackEric, Вы писали: BE>А чем не устраивает поднять еще один ms sql? FB — это тоже субд, разве что может работать под linux.
Если есть маленькие шустрые кросс-платформенные MS SQL-серверики для работы с одним файликом — то, устраивает.
С> Какой смысл брать что-то маломощное, sqlite какой-то, сеть к нему прикручивать, если можно сразу использовать полноценную СУБД?
Зачем использовать полноценную СУБД для однопоточной работы с одним файлом?
W>Firebird, Мускул/Мария, Postgre, что угодно. Выбирай то, что лучше знаешь (я так понял, что NoSQL ты поэтому отмел). Ну и по лицензиям смотри, у многих есть dual licensing. W>Но SQL гонять через интернет не советую, хлебнешь лиха. Делаешь простейший REST API, и выбор становится намного шире, а жизнь комфортнее.
Поверхностные знания по всем. NoSQL я отмёл по той же причине, что и самописные сервисы — с одной стороны SQL, с другой неведомая хрень. Между ними нужно будет наладить взаимодействие. А хочется единый интерфейс малой кровью. Да, можно парсить SQL-запросы и превращать их в команды собственного API. Зачем?
W>Делаешь простейший REST API
Простейший REST API не поддерживает персистентную коннекцию и транзакционность.
Ищется решение из коробки. А так проще написать собственный TCP сервер, который будет принимать входящие запросы и форвардить их локальной SQLLite-базе.
> Ищется решение из коробки. А так проще написать собственный TCP сервер, который будет принимать входящие запросы и форвардить их локальной SQLLite-базе.
Здравствуйте, LWhisper, Вы писали:
LW>Здравствуйте, BlackEric, Вы писали: BE>>А чем не устраивает поднять еще один ms sql? FB — это тоже субд, разве что может работать под linux. LW>Если есть маленькие шустрые кросс-платформенные MS SQL-серверики для работы с одним файликом — то, устраивает.
On 23.12.2015 17:14, LWhisper wrote: > *Задача:* > Выгрузить часть данных из MS SQL в отдельный файлик и положить его на > удалённый Linux\Windows хост с возможностью последующего обновления > посредством SQL-запросов (Insert, Update, Delete). > > *Что подходит:* > Заливка, установка и запуск на хосте службы/демона/процесса, который > будет принимать входящие соединения и устанавливать персистентное > соединение, принимая команды и отдавая данные из этой базы-файла. > Достаточно одного соединения, параллелинг не обязателен (хотя и > желателен). Наличие транзакций. Хорошая производительность. Клиент на > Windows.
Здравствуйте, LWhisper, Вы писали:
LW> BE>А чем не устраивает поднять еще один ms sql? FB — это тоже субд, разве что может работать под linux. LW> Если есть маленькие шустрые кросс-платформенные MS SQL-серверики для работы с одним файликом — то, устраивает. http://h2database.com/
