Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Встраиваемые СУБД  [new]
eNose
Member

Откуда:
Сообщений: 183063
А давайте не путать XMLDB:API, что является средством доступа, с форматом хранения.
Изначально ведь речь шла именно о формате.
А XMLDB:API можно прикрепить к чему угодно. Так же как и SQL.



eNose
29 окт 03, 12:05    [397560]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
sboronin
Member

Откуда: www.outdoor.ru
Сообщений: 15
2 eNoise

http://www.sleepycat.com/products/xml.shtml

С уважением,
Боронин Сергей
29 окт 03, 12:05    [397564]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
eNose
Member

Откуда:
Сообщений: 183063
Оттуда (http://www.sleepycat.com/products/xml.shtml), самая первая строка в overview:

Berkeley DB XML is an application-specific native XML data manager built on Berkeley DB.

Ну и? Это обычный XML API для СОВЕРШЕННО ДРУГОГО формата.



eNose
29 окт 03, 12:11    [397576]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
sboronin
Member

Откуда: www.outdoor.ru
Сообщений: 15
>А давайте не путать XMLDB:API, что является средством доступа, с форматом >хранения.
>

Никто и не путает, ведь мы сравниваем SQL-доступ с XMLDB:API доступом, т.к. это средства доступа.
Вот если бы мы сравнивали dbf и XML-файлы, тогда речь шла бы о форматах хранения.

>Изначально ведь речь шла именно о формате.
>

Если так давайте сравним DBF-файл и XML-файл, я думаю что примущество будет не за dbf :)

>А XMLDB:API можно прикрепить к чему угодно. Так же как и SQL.
>

С этим согласен, например в Nimble после того как будет реализован XMLDB:API будет реализован и SQL-доступ для облегчения миграции с SQL на XMLDB:API

С уважением,
Боронин Сергей
29 окт 03, 12:12    [397580]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
sboronin
Member

Откуда: www.outdoor.ru
Сообщений: 15
2 eNose

>>Оттуда (http://www.sleepycat.com/products/xml.shtml), самая первая строка в >>overview:
>>Berkeley DB XML is an application-specific native XML data manager built on Berkeley >>DB.
>>
>Ну и? Это обычный XML API для СОВЕРШЕННО ДРУГОГО формата.
>

Ну, так никто и не говорит что база обязатльно должна представлять собой XML-файл, она предоставляет XMLDB:API который в свою черед предоставляет DOM, а что есть DOM, как не объектное представление XML? :)
При желании, DOM-объект можно сохранить как XML-файл, например для огранизации экспорта-импорта.
Формат самой базы не важен, когда есть XMLDB:API.
Так же, как вам не важен внутрений формат хранения MS SQL при SQL-доступе!

С уважением,
Боронин Сергей
29 окт 03, 12:19    [397594]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
eNose
Member

Откуда:
Сообщений: 183063
Боронин Сергей!
Вот выдержки из Ваших постов:

396492: Вынужден с вами не согласиться, т.к. вымирание ожидает реляционки, как морально устаревшие, а BerkleyDB и Nimble двигаются в направлении бинарных XML-based СУБД

396599 XML это не мода - это будущее, в MS и Oracle не дураки же сидят. А ООБД свое еще возьмет, наример Cache и Fast Objects живут себе и здравствуют.

396621 Например работу с индексами в XML-based СУБД можно доверить самой СУБД

397469...Нормализованные БД на binary XML-based можно обрабатывать используя...
...XML гораздо легче ложится на объектную структуры, чем SQL...
...любая XML-база легко расширяема...



А вот из последнего: Никто и не путает, ведь мы сравниваем SQL-доступ с XMLDB:API доступом, т.к. это средства доступа.


Так о чём Вы говорите: о хранении или о доступе?


eNose
29 окт 03, 12:22    [397605]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну все же это уход в сторону - XML это одно, а движок БД, которая хранит данные на XML это другое. Это такой же движок, как и любой движок любой БД, которые имеют свои форматы хранения данных. И причем тут получается XML? Да ни при чем. Результат в нем? Дык я результат и из MS SQL верну так.
А на кой мне XML в Дельфи например? Да не нужен нифига. И зачем тогда БД на XML делать?

Не, я все же не пойму - чего в XML то так ударились? А почему не в dbf, txt еще чего там... Как универсальное средство для передачи данных между совсем разными приложениями - да, как панацея да еще БД - это уж слишком


-- Tygra's --
29 окт 03, 12:26    [397624]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
sboronin
Member

Откуда: www.outdoor.ru
Сообщений: 15
2 eNose

>Так о чём Вы говорите: о хранении или о доступе?
>

В первую очередь о доступе, но в связи с тем, что DOM является объектной можелью XML говорить о доступе не говоря о XML как о способе представления данных не получается.

У вас есть еще аргументы, кроме придирок к словам и формулировкам?

С уважением,
Боронин Сергей
29 окт 03, 12:27    [397626]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
f2f
Guest
-- Нормализованные БД на binary XML-based можно обрабатывать используя XMLDB:API без потери в скорости выборки, в отличие от реляцтонок которые теряют в производительности при нормализации, особенно если это 4НФБК или 5НФ

--Меньше требуется кода для поодержки целостностид связанной с нормализацией


Тут требуется пояснение - это почему ?


--Более естественное, древовидное представление данных

Смотрю на свои базы и не могу себе представить из в виде дерева

Клиенты - отдельно
Валюта - отдельно
Договор - ну ладно можно засунуть внутрь клиента
Сделка - связана с двумя договорами (так надо). Так что тоже отдельно
Проводка - в данном случае можно засунуть внутрь сделки. Хотя здесь есть сомнения
Счет - отдельно

У меня что-то не дерево получатся, а в лучшем случае лес.
Или это мое косное мышление ?
29 окт 03, 12:31    [397636]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Дык у меня тоже дерево не получается - как складской учет в дерево запихать?

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

-- Tygra's --
29 окт 03, 12:38    [397653]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
Я
Guest
--Более естественное, древовидное представление данных

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

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

Реляционная модель как раз и хороша тем, что просто описывает данные и связи между ними в не жестко забитых и связанных структурах.
В этом сила реляционной модели: она предоставляет возможность одновременно поддерживать несколько различных представлений на одни и те же данные, в этом и ее слабость, не все эти представления являются "естественными". Пример для одного приложения список сотрудников является атрибутом отдела, возвращаем ему объект - отдел с атрибутом "список сотрудников", для другого приложения отдел это лишь атрибут сотрудника, возвращаем ему, допустим, XML файл со списком сотрудников где одним из атрибутов для каждого сотрудника является отдел.

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

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


P.S. А насчет роли Java в Oracle вы глубоко заблуждаетесь...
29 окт 03, 12:39    [397655]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
Я
Guest
Так мы уже говорим о представлении, а не о хранении...

Тогда вообще не понимаю о чем спор, представляйте как вам удобнее
и как лучше для ваших целей...
29 окт 03, 12:48    [397676]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Например, сможете ли вы одним SQL-запросом получить все данные о документе, например счете, содержащем 150 деталей? Сомневаюсь а на xpath-легко!
Я вот хоть убей не пойму этого выражения. Что - select * from Account inner join Details - это супер сложеный запрос что ли ? Или имеется ввиду получение данных в виде XML клиентом ? Тогда простой пример из BOL:
SELECT

1 tag,
NULL parent,
emp_id [emp!1!id],
emp_fname [emp!1!name],
NULL [order!2!date],
NULL [dept!3!name]
FROM employee
UNION ALL
SELECT
2,
1,
emp_id,
NULL,
order_date,
NULL
FROM employee KEY JOIN sales_order
UNION ALL
SELECT
3,
1,
emp_id,
NULL,
NULL,
dept_name
FROM employee e JOIN department d
ON e.dept_id=d.dept_id
ORDER BY 3, 1
FOR XML EXPLICIT

На выходе:
<emp id="102" name="Fran">

<dept name="R & D"/>
</emp>
<emp id="105" name="Matthew">
<dept name="R & D"/>
</emp><emp id="129" name="Philip">
<order date="2000-07-24"/>
<order date="2000-07-13"/>
<order date="2000-06-24"/>
<order date="2000-06-08"/>
...
<dept name="Sales"/>
</emp><emp id="148" name="Julie">
<dept name="Finance"/>
</emp>

И в любой современной РСУБД этих методов работы с XML до чертиков сейчас. Вышеприведенный пример взят с ASA9 - там чего только нет - и генерация XML как угодно и по какому угодно формату и поддержка XQuery и встроенный прямо в СУБД http сервак, для которого прямо на самой ASA можно писать всякие web сервисы: HTTP, HTTPS, XML, RAW, SOAP, DISH (лично я еще не придумал, что с этим всем делать). Насколько знаю в других РСУБД тоже народ не спит и все это уже не новость.

Дык зачем же нам XMLDB ??? Я вот читал не так давно статью по поводу, что будет в новом стандарте SQL2003 (вот только ссылку найти так и не смог :( ). Там четко и ясно сказано - полностью стандартизированна поддержка хранения и обработки обьектов и XML для SQL. Сказано и зачем - чтобы SQL жил и процветал. В этой статье действительно XML называется теоретическим конкурентом SQL, поэтому чтобы сего не было, он должен быть поглощен. Что и будет скорее всего, как ранее произошло с ООБД. Причем никто особо и не против - релляционная модель математическая и строгая, SQL самодостаточный, а в кач-ве одновременно достоинства и недостатка XML называют его раскрепощенность в области описания данных. Поэтому производителям ПО легче все делать на SQL, а XML пользоваться действительно как универсальным форматом передачи данных. Высказывания не мои, а с той статьи, с XML не работал, поэтому как прочитал, так и пересказал :)
29 окт 03, 13:05    [397746]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
eNose
Member

Откуда:
Сообщений: 183063
Боронин Сергей писал:
У вас есть еще аргументы, кроме придирок к словам и формулировкам?

А это не "придирки" были, а Ваши слова, где Вы восхваляли бинарные XML-based СУБД.
А как только тема стала для Вас неудобной (ну нечего там восхвалять), Вы перешли на XMLDB:API.

Так что меня обвинять не надо.

Теперь про XML: я (как и Tygra) совершенно не понимаю, зачем мне XMLDB:API в Делфи?
Мне Delphi+PL/SQL за глаза хватает.

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




eNose
29 окт 03, 13:48    [397885]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 sboronin
автор писал:
Например, сможете ли вы одним SQL-запросом получить все данные о документе, например счете, содержащем 150 деталей? Сомневаюсь а на xpath-легко!


А не продемонстрируете как на xpath получить сумму нарастающим итогом? А так же группировку с суммой. Моих знаний xpath не хватает для этого. Буду признателен.
29 окт 03, 14:39    [398041]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
2Ermak
--Дайте четкое определение, что такое ''XML база данных".

формально это иная организация обычной реляционной базы. В данном случае XML - надстройка на существующей базой. Обычные таблицы мапяться в соответствующие ноды. Появляется понятие - логическая группа таблиц, то есть вместо 500 таблиц в списке появится дерево в таблицами в ветках.

Ряд системных таблиц исчезнут, а данные перейдут в соответсвующие системные ноды. Расширится список атрибутов таблицы и нода.

Для конечно юзера будет просто расширение синтаксиса за счет новых функций и убирания старых.

Формально ряд запросов станет проще

--После этого будем разбираться дальше, убъет XML БД реляционные СУБД или нет.

Вряд ли.

2Glory

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

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

--А если не сможет, то присоединюсь к U-gene - какая нафиг разница каков _внутренний_ формат хранения данных в БД ???

Формат можно и не менять - только принципы работы с базой.

2eNose
--А XML файл справится с данными объемом 20 GB?

А в чем пробема ?
29 окт 03, 18:48    [398752]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор писал:
--Если после появления всех этих "наворотов" вы мне скажите что кто-угодно по прежнему сможет запросто открыть xml файл, являющейся частью базы данных в том же Notepad, т.е. в обход ядра базы, то я просто умру от смеха.

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


Смешное то, что этот вопрос относится к индексам, триггерам и т.д. И как нотепад будет индексы читать?

-- Tygra's --
29 окт 03, 19:03    [398771]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
Glory
Member

Откуда:
Сообщений: 104751
Lepsik писал:
а что тут смешного ? и почему бы и нет. ноутпад не будет зачитывать файл с диска, а будет мапить из памяти. Не вижу ничего странного или необычного.


Чего-чего ? Мапить из памяти удаленного сервера ?
29 окт 03, 19:17    [398786]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
Я вот чего не понимаю... топик начался про встраиваемые СУБД, а теперь идет обсуждение XML да XMLDB:API... Это что, попытка увести обсуждение в сторону или просто незнание предмета обсуждения?.

Встраиваемая база может быть как объектная, так и реляционная. А в каком виде она уже представит свои данные и как позволит с ними работать - это другая песня, это уровень представления данных, хоть SQL, хоть XML или OQL суть параллельно.

Сходу здесь уже предлагали разные варианты встраиваемых СУБД, к примеру Fast Objects (Объектная база) и Firebird (ну и прочие указанные в топике).

Почему я раньше писал, что не сравниваемое - потому что у того же MS SQL (да и у других выделенных серверов) до черта разных прибамбасов... например, репликация. В случае встраиваемой базы я уверен, придется писать самостоятельно. Да много еще чего. С другой стороны, скорость работы встроенной базы может быть намного больше, если правильно спроектирована структура.

PS. я считаю что обсуждение собственно преимуществ и недостатков встраиваемых СУБД намного интереснее (и полезнее), чем половина написанного в треде.
29 окт 03, 20:29    [398833]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
alex_k
Member

Откуда: krasnoyarsk
Сообщений: 6694
что касаемо FireBird fbembeded
то плюсы которые я вижу - это отсутствие сервисов, висящих в памяти да принудительное ограничение пользователя в 1 коннект.

может быть скорость будет больше засчет однопользовательского механизма доступа, незнаю.
29 окт 03, 22:30    [398862]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
c127
Guest
AAron

>Почему я раньше писал, что не сравниваемое - потому что у того же MS SQL (да и у других выделенных серверов) до черта разных прибамбасов... например, репликация. В случае встраиваемой базы я уверен, придется писать самостоятельно.

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

2 alex_k

А можно ли встроить FB в клиентское приложение, написанное на VB, VFP, PB, т.е. в приложения, не строящие независимый екзешник? Как встраиваемый сервер взаимодействует с ODBC драйвером, т.е. нужно ли конфигурировать ODBC при инсталляции и куда вообще складывается ODBC драйвер? Я не смог найти эту информацию в интернете.
30 окт 03, 00:40    [398899]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
c127
Guest
вместо ultralight следует читать ultralite.
30 окт 03, 05:06    [398921]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
sboronin писал:
Вот неполный список преимуществ:

-- Нормализованные БД на binary XML-based можно обрабатывать используя XMLDB:API без потери в скорости выборки, в отличие от реляцтонок которые теряют в производительности при нормализации, особенно если это 4НФБК или 5НФ

? Это приемущество? То есть способ выборки - это приемущество? Чудес не бывает - если где-нибудь что-нибудь прибыло, то где-нибудь что-нибудь обязательно убыло. Выигрывать в скорости за счёт принудительной денормализации, а точнее - отказа от нормализации как таковой я не согласен
sboronin писал:

--Меньше требуется кода для поодержки целостностид связанной с нормализацией

Да Вы что? Правда-правда? А теперь пожалуйста - с примерами. Нарисуйте мне "дерево" с вложениями одного и того же объекта в разные ветки и нарисуйте как должен выглядеть оператор изменения данного объекта.
sboronin писал:

--Более естественное, древовидное представление данных

На этот счёт Вам уже очень хорошо ответили. Древовидное представление - не самое естественное.
sboronin писал:

--Работа с DOM-объектом удобнее, чем с кучей рекордсетов, предоставляющих тот же набор данных

Вот тут готов согласиться. Иногда - удобнее. Я предпочитаю получать ОДИН рекордсет и работать с ним. Однако никто не мешает взять несколько рекордсетов и получить из них DOM объект (ADO.NET делает это со свистом). И при чём тут XML DB?
sboronin писал:

--Для получения тех же данных требуются более простые запросы, например для получения счета достаточно сделать 1 XPath-запрос к базе, при этом будет получена и шапка счета и детали счета.

То есть Вы храните "счёт". В дереве. Угу. А теперь напишите мне XPath запрос для получения товаров, поставленных в последний месяц, сумма по которым превышает среднюю за тот же месяц.
sboronin писал:

--С сохранением измененых данных тоже проблем никаких, либо сохраняется целиком DOM-объект, либо используется xpath-запрос, и хотя xpath не входит в DOM2, но он есть в XMLDB:API

А как быть с валидацией полученного в результате XPath запроса документа?
sboronin писал:

--XML гораздо легче ложится на объектную структуры, чем SQL

Приехали. Да, ложится. И там лежит. Ну и что? SQL не обязан туда ложиться - и он этого не делает. Почему все считают, что объектный подход - это серебряная пуля от всех бед?
sboronin писал:

--XML позволяет легко и естественно работать с n-мерными данными, а в "плоском" SQL для этого надо изголяться

Вот ещё. Вовсе не надо.
sboronin писал:

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

Ну и прекрасно. В SQL точно так же. Я добавляю новые таблицы и колонки, а старый код как работал так и работает.
sboronin писал:

Например, сможете ли вы одним SQL-запросом получить все данные о документе, например счете, содержащем 150 деталей? Сомневаюсь а на xpath-легко!

Легко!
30 окт 03, 07:13    [398952]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
Ermak
Member

Откуда: Tomsk
Сообщений: 811
Когда говорим реляционная СУБД, то преджде всего подразумеваем модель данных.
См. статью Кодда. Реляционная модель данных для больших совместно используемых банков данных

(Кроме собственно реляционной модели данных есть ещё сетевая и иерархическая (объектная ???). Мне кажется, что XML есть разновидность именно иерархической модели данных.)

2 sboronin
Давать определение XML СУБД с точки зрения "движка, предоставляющего XMLDB:API" - это несерьезно. К тому же существует такая XML СУБД как Tamino, однако на сайте в описании этого продукта (http://www.softwareag.ru/ino/short_info.asp) наличие XMLDB:API, там не упоминается: "В Tamino использована философия открытых СУБД, сервер содержит стандартные интерфейсы: OLE DB, DCOM, ODBC и JDBC." Попробуйте ещё раз дать определение XML базы данных.

2 Lepsik
Давать определение XML СУБД как "формально иной организации обычной реляционной базы" на мой взгляд также несерьезно.


Наличие XML надстройки не сделает реляционную СУБД - иерархической. Поймите, что "любые реляционные данные могут быть непосредственно отображены в XML, но не наоборот... XML поддерживает упорядоченное хранение данных, а реляционное представление нет."
30 окт 03, 07:35    [398960]     Ответить | Цитировать Сообщить модератору
 Re: Встраиваемые СУБД  [new]
Roman Ignatiev
Member

Откуда: Москва
Сообщений: 680
2c127 Встроенный сервер Firebird или Yaffil с клиентской стороны ничем не отличается от обычного клиента, ограничения - только одно приложение и локальный коннект без имени сервера, если указать сетевой - будет пытаться соединится с сервером и работать как обычный клиент :)
В остальном употребление ничем не отличается
30 окт 03, 09:56    [399107]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить