2 iscrafm

Да. Все это имеет значение как сетевая архитектура многопользовательских СУБД. Моно еще вспомнить телеобработку до кучи. На одном компе все это мало что меняет - предельный случай (типа нулевая сеть). Там она затерялась бы среди прочих архитектр приложений. Так мне все еще кажется.

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

Уже, по-моему, када переписывал этот шедевр для Вас сюда.

Пьяный Лох
Кто сказал, что СУБД обязана быть многопользовательской, а если однопользовательская - то уже не СУБД?

Все еще СУБД.

Пьяный Лох
Кто сказал, что СУБД не должна уметьт работать с Read Only базами?

Уметь должна. Но и уметь обновлять должна. А в той встроенной, про которую kdv это не надо. Это моно выкинуть из Дээллельки. Пусть по Вашему все читалки СУБД. Я, например, пока больше на Томаса Конноли и др буду ориентироваться.

Пьяный Лох
Никаких самых первых ф-й там нет.

Про обновлять, удалять там все же было.
1 Ф-я СУБД - Хранение, извлечение и обновление данных.

Пьяный Лох
Добрые люди Вас обманули, а Вы и повелись.

Намерен и дальше так поступать.

Пьяный Лох
И что дальше? Скуль - СУБД. У Скуля ОЛАП - отдельный сервак. Что дальше? По другому - нельзя? Патамушта "добрые люди" так сказали?

То что это показывает Вам, что я не считаю, что ОЛАП обязателен для СУБД.
Больше ничего. Вам же мало, что я это уже сказал. Вы в тексте выискиваете, что я мог так не думать.

Пьяный Лох
Ну да, ну да, давайте теперь свои же слова перевирать.
Сначала Вы усомнились в том, что в 5МБ можно уместить помимо СУБД еще и ОЛАП, и следующим же предложением заявили, что дескать "Значит 5 Мб - это не полный даже движек, а не то что СУБД"
Если теперь заявляете, что это Вы не про требования СУБД, то как же понять Ваши слова, что раз в 5МБ ОЛАП не влезет, то значит это даже не полноценный движок, не говоря уже о СУБД?

Там же вопрос стоял. А не утверждение, что его нет. Поэтому вывода на основе того, что там нет ОЛАПа быть не может. Я его и не делал.
Во фразе про "значит" имелось в виду, что раз сам АСА 10 Мб и равен по функционалу движку, но движек меньше в двое, то его типа могли коснуться урезания. Но, наверное, Вы правы я не удачно выразил это. Там должен был стоять вопросительный знак. Опечатка.



Пьяный Лох
Какая разница во сколько мегабайт оно уместилось?
У сиквела дистрибутив занимает два компакт диска. ASA занимает 10 мегабайт. Что с того?

Вы считаете ничего? Меня некоторые сомнения все-таки до сих пор одолевают.

Пьяный Лох
Я то читаю, в отличие от Вас. Вы, похоже, даже не думаете прежде чем писать.

Хорошо. Пусть так. В конце концов нам не зачем восхищаться мыслями друг друга.

Пьяный Лох
Понятно. Чукча не читатель, чукча писатель.
Вопросов к чукче больше не имею.

Думаю, это дает мне право на них не отвечать.

kdv
клиент-серверная. Приложение думает, что общается с клиентом. Сервер в DLL думает, что получает запросы по сетевому протоколу (якобы) от клиента.

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

kdv
ХКП. Firebird Embedded позволяет создавать БД и все остальное. Я еще раз повторяю, что приложение понятия не имеет, что вместо обычного клиента "серверной СУБД" ей подсунули Firebird Embedded.

Хорошо. Хотя если тока читает, то зачем ей собсно создавать? Создать могла и не Firebird Embedded, а просто Firebird. Ить это, наскока я понял, не нужно в процессе эксплуатации такой парочки.

kdv
Функциональность идентичная целиком и полностью. Да, DLL не будет принимать чужие сетевые коннекты. То есть, это как бы "персональный сервер" для приложения.
FB Embedded компилируется путем исключения из кода сервера поддержки сетевого протокола, грубо говоря. Понятно?

Тока сетевого протокола? Мож еще чего? Каких-нить диспечеров блокировок?
Впрочем, понятно.

kdv
я не пойму, ты прикидываешься, или как? К чему нести какую-то ахинею? Или это популярно в разделе "Сравнение субд"?

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

kdv
файл-сервер, это когда каждое приложение содержит "движок" доступа к файлам БД. клиент-сервер, когда файлом БД занимается только сервер.

В самом деле? Бум иметь в виду. А у файловых систем - это которые без СУБД, что содержится в приложениях? Впрочем, мне к счатью больше приходится иметь дело с не встроенными СУБД. Без "движков" и с многопользовательскими СУБД проще про ФС и КС. На кажном клиенте стоит СУБД выполняет запросы, а на файл сервере данные - ФС, на сервере БД серверная часть СУБД и там выполняет запросы - КС. Да и с однопользовательскими - ни ФС и ни КС.

2 iscrafm
У Вас про СУБД, нет ни слова. Такие обобщенные определения, мож, и подходят для программирования вообще. И не зависят от сети. Например, COM, а с сетью DCOM (но там ФС особо не выделяют). Типа вроде бы более общее. Но часто сервер - тот кто выполняет запросы клиента, а клиент тот кто из посылает. И в ФС клиенты тоже общаются тада с посредником Файл - Сервером (это тоже сервер (посредник)). А уж он с ресурсом, хотя в общем случае и не единственный - как налабать систему.
Для многопользовательсеких СУБД есть еще архитектуры многозвенные (многослойные). Там есть, например, сервера приложений. С ними может общаться клиент. А они тоже типа не с "ресурсом" общаются, а "Сервером (посредником)", а тот единственный или нет, общается с другими серверами или ресурсами. Ну при желании на этот сервак моно впендюрить и те СУБД, что относят к ФС. Это все нуно как-то уточнять в Вашем определении.
А без сети для СУБД от таких понятий пользы все еще не видно. Если все такие клиенты и сервера на одном компе, особой разницы между ФС и КС вроде и нет в плане БД. Потому что не тока Ваш "ресурс" (Диски там или файлы - как вы его определяете теперь и не знаю) , но и все остальные там же, а сетевых нет.
А то определение просто и тока про СУБД. И польза и недостатки с ресурсами, включая и сетевые, как бы более или менее видны. А это главное почему их делят на КС и ФС вообще.

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

А чего мне настораживаться? Я всегда допускаю, что могу быть не прав. Если в их словах есть что-то рациональное возьму на вооружение. Лучше здесь ошибаться, чем в реале. Тем более про встроенные СУБД я впервые услышал. Про движки слышал. Считал их ядром или отдельными компонентами СУБД. Так шо польза есть

mir
Вам уже объяснили, а я присоединяюсь, что есть такой полезный вид СУБД -- встраиваемые СУБД. Это зачастую спец. версии обычных СУБД, в которых выкинут параллельный досту и вообще сетевые функции. Встраиваемые СУБД нужны, когда конкртное приложение нуждается в работе со своей БД, но при этом совсем не нуждается ни в сети, ни вообще во "внешней", отдельно устанавливаемой и администрируемой СУБД. При этом встраиваемая СУБД является как бы частью самого приложения (в этом и суть термина "встраивание"), вместе с ним инсталлируется и вместе с ним же деинсталлируется.


Да, наверное. Есть, конечно, еще какие-то сомнения. Так как в общем случае ей не все нужно от СУБД, ить без приложения с помощью этой СУБД возможно и не предполагается работать с этой БД. Впрочем, это может и не важно.
Главное, понятно теперь. Хотя не настока, чтобы допереть про встроенный Оракл, про который в той ссылке. Если это Персональный Эдишен, то ему по прежнему начихать на любые приложения. А что это еще может быть пока не знаю.

kdv
и правда, комедия. Объясняешь человеку про конкретную реализацию, а он в ответ какие то полные фантазии по поводу файл-сервера, да еще и сомнению все подвергает.
"Урезаный? Нет? Точно? А может, все-таки урезаный?".
Конечно, сомневаться можно и нужно, но не до такой степени.

Конкретная реализация - это же тока пример. Ваши мысли про сервера тоже врядли стоит вставлять в солидные книги. А сомнения есть. В плане маленьких систем, возможно, вообще нет разницы СУБД там или просто кто-то свою читалку к dbf - файлам написал. Но там в ссылке сравнения реальных, и чуть ли не мировые топ-листы. Там, возможно, не о мальньких системах идет речь. Мож о больших проектах. от тут до какой степени сомненеваться и не очевидно. Но все равно спасибо, что на примере FB рассказали. На примере клиппера я знал. Осталось понять есть ли примеры на СКУЛе, Оракле и ДиБИва2.

kdv
В данном случае тут "моих мыслей" нет. я излагаю то, что является ФАКТОМ. Если со своей колокольни Вам это тяжело воспринять, то это ваши проблемы.

Не стока тяжело, скока не зачем. Даже если Ваш авторитет не прирекаем где-то, этоn якобы ФАКТ предпочту пока отвергнуть, с тем чтобы у меня было меньше проблем.

kdv
То есть. делаем обычное клиент-серверное приложение. Если вдруг потребовалось его ПОКА (или совсем) поставить на ОДИН компьютер, то вместо СЕРВЕРА на этот компьютер кидаем Embedded.
В итоге, не надо сервер запускать перед стартом приложения, и т.п.


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

В общем Ваш тот пример был лучше. Моно не продолжать.


kdv
если так туго идет - представь себе Оракл, который запихнули в oci.dll, целиком.

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

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

Скорее всего.
Согласно ссылке, что дал iscrafm - IDC, там на третьем месте Оракл нарисовался. Упоминаются его конфигурации "встроенности", при которых он, вроде как, не нуждается в администрировании. И эта "встроенная" СУБД еще и на третьем месте. Возможно, Personal Edition, возможно, с урезанными сетевыми, по, крайней мере, их тада не надо администрировать. Надо будет при случае на сайте Оракловом поискать.
Кто такие эти парни от IDC? Может у них есть какая-то заинтересованность? Например, Кеша на вторую позицию протолкнуть? И назвают его Постреляционным.