Есть ли способ выдать себя за конкретное ядро ​​базы данных при запуске другого?

Question

Это то, что я хотел бы видеть, работая сегодня, программируя, но я еще никогда не видел такого приложения. Ваш вклад высоко ценится.

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

В таком случае это может быть непростой задачей при первой установке MSSQL. Я предлагаю что-то вроде программного моста, который может использовать другую СУБД для хранения данных. Другими словами, приложение «видит» экземпляр MSSQL, но под ним может быть Access. Мост должен сделать какое-то преобразование.

Другой пример: у вас есть MSSQL, но для определенного приложения требуется Oracle. Вы должны купить Oracle тогда. Но с чем-то вроде моста, вы можете поместить информацию в вашу СУБД MSSQL. Мост прислушивается к порту 1521, как Oracle, поэтому приложение «Думает», что происходит установка Oracle.

1. Это идея, которая не может быть реализована?

2. Есть ли такие приложения?

3. Если да, то что они?

Спасибо ...:)

Добавление пояснения: приложение может быть от третьей стороны. У вас нет никаких знаний о внутренней архитектуре этого. Вы просто знаете, что он использует определенную СУБД. Я пытаюсь использовать другую СУБД, отличную от сторонней программы.

Answer 1

Приложение обычно не зависит от конкретного сервера базы данных, ИЛИ они зависят от него по какой-либо причине.

Если приложение запрашивает oracle, или сервер sql, или что-то еще, это потому, что оно полагается наподробности реализации этого конкретного поставщика для запуска его SQL, его хранимых процедур и т. д. Вы никак не могли бы эмулировать это с базой данных доступа, например ...

Если вашему приложению просто нужно запустить несколько очень простыхSQL (т. Е. Базовые операторы вставки / выбора), он, вероятно, использует стандартный драйвер (odbc, ado и т. Д.), И эти драйверы могут работать с любыми основными механизмами базы данных sql.По моему опыту, «простые приложения» не запрашивают конкретного поставщика базы данных.

Answer 2

Это проблема, которую ODBC должен был решить :-).

Но в ответ на ваши вопросы:

Это идея, которая не может быть реализована?

Может быть реализовано.

Это была бы утомительная и неблагодарная работа, и у вас была бы очень ограниченная аудитория. На мой взгляд, это не стоит делать.

Есть ли такие приложения?

Ни одного, о котором я знаю.

Если так, то кто они?

Ничего из того, что я знаю.

......

Внесение записки Чандрасекара в разделе комментариев:

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

Я согласен, что у него есть приложения, но у него очень ограниченная аудитория :).

То, что вы предлагаете, это что-то вроде плагина firefox 'ietab', только у вас его не будет установлено, то есть ... поэтому вместо встраивания, то есть вам нужно будет полностью повторно реализовать, то есть использовать окно рендеринга в firefox.

Только мое мнение: это слишком много усилий ... Проще просто установить вторую базу данных.

Answer 3

Приложения обычно ДОЛЖНЫ зависеть от конкретного сервера базы данных. Каждая база данных реализует вещи немного по-своему - даже MSSQL и Sybase, которые имеют общего предка.

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

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

Короче говоря, я не думаю, что это риск того, что приложение будет работать со сбоями и остаться без поддержки, даже если приложение не особенно важно. Если вам не нравится базовая база данных, которую использует приложение, выберите другое приложение.

Answer 4

Самое близкое, что я слышал, это EnterpriseDB, где они построили слой поверх Postgres, так что он больше похож на Oracle.

Но помните, что эти базы данных имеют функции, защищенные патентами и авторскими правами, поэтому существует ограничение на то, насколько близко конкурирующий продукт может имитировать реальную вещь.

Вероятно, было бы легче имитировать «вниз», чем вверх. Например, MS-Access не сможет имитировать большую часть функциональности Oracle или SQL Server, тогда как у SQL Server гораздо больше шансов на имитацию более простой БД, такой как Access.

Answer 5

"Это проблема, которую ODBC должен был решить :-)."

И это та же проблема, которую SQL должен был решить.

Мне кажется, что причина этой проблемы заключается в том, что мир, по-видимому, не может договориться достаточно о том, как должен выглядеть язык / интерфейс манипулирования данными.

Я подозреваю, что если бы это было решаемо, это уже было бы сделано.

Answer 6

Если это приложение использует ADO для подключения к SQL Server и вы можете изменить строку подключения, тогда довольно просто использовать другую базу данных: измените строку подключения! Однако другая база данных должна поддерживать все функции SQL Server. Кроме того, программное обеспечение никогда не тестировалось на другой базе данных, поэтому приложение может быть Crash & Burn.

Если вы не можете изменить строку подключения или приложение не использует ADO, все становится более сложным и очень близким к невозможному.

В прошлом я работал над проектом, который должен был быть разумно независимым от базы данных. База данных должна была поддерживать хранимые процедуры, но других ограничений не было. По умолчанию мы пытались поддерживать как SQL Server, так и Oracle. (Мы также поддерживали Interbase, но никогда не рекламировали это.) Хотя нам удалось сохранить его в основном независимым от базы данных, нам пришлось обойти немало незначительных проблем. Особенно у соединений в наших запросах были некоторые неприятные проблемы, которые мы просто решили, добавив больше логики к хранимым процедурам.