Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 25   вперед  Ctrl
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
2ASCRUS

да, аксес я видел 2 раза когда промахивался в иконках у офиса :) но в детстве первый сексуальный опыт был имеено с VFP :)

итак читаем:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_foxhelp9/html/0fb84e4f-be70-480b-9047-5dd69be056bd.asp
автор

Apartment-Model Threading

Visual FoxPro Automation servers now support Apartment-model threading. The Microsoft Transaction Server utilizes servers marked as apartment-threaded and offers better thread protection and scalability through serialization and marshaling.

In Visual FoxPro, apartment-model threading provides thread safety. In apartment-model threading, each thread is like an apartment — all objects created on the thread live in this apartment, and are unaware of objects in other apartments. Each Apartment-model object (such as a Visual FoxPro Automation server) may only be entered by one thread, the thread that created the object. However, an object server (such as Microsoft Transaction Server) can support multiple objects, each being entered simultaneously by different threads. Common data held by the object server must be protected against thread collisions.


а теперь объясните мне глупому чем Visual FoxPro Automation servers у вас принципиально отличается от сиквела ?
28 апр 05, 11:57    [1504616]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Yo, ну не позорься ты, ей богу...
Вопрос "чем OLE Automation Server отличается от MS SQL Server'а" - это нечто из серии "чем DLL отличается от DB2"

В огороде бузина, а в Киеве дядька.
28 апр 05, 12:16    [1504715]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
чем отличается я знаю, я пытаюсь вытянуть определение из ASCRUSа.
28 апр 05, 12:23    [1504752]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ASCRUS

Гм - а что, на одном компьютере/КПК я уже не могу запустить 2 приложения одновременно - например программу с интерфейсной частью и отчетную систему ?


Однопользовательские <> однозадачные.

Вы вот опишите, чем в вашем случае КС-система будет отличаться от ФС. И тогда мы поговорим о рациональности КС для такой задачи.

ASCRUS

Да что Вы говорите - у меня на КПК уже давно стоит ASA, достаточно эффективно работает с приложениями, написанными на PocketPB и C#, выполняет полноценные SQL запросы, обеспечивает ссылочную целостность и каскады, делает бакупы, через оффлайн репликацию гоняет данные между собой и консолидированной БД, точка доступа к которой обозначена через FTP хоста нашей конторы.


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

ASCRUS

Ну ка сляпайте мне все это на ФС, которые проникают на рынок мобильных устройств, где уже не один год КС РСУБД ASA занимает лидирующие 80% рынка - ну ну ... :)


Плывут пароходы - салют мальчишу! Идут пионэры - салют мальчишу ...

Мы о конкретных продуктах говорим или о КС и ФС архитектурах вообще? Потому как если о продуктах, то и сравнивать надо потребительские характеристики, а не внутреннюю архитектуру. Конечному пользователю глубоко по барабану, как оно там внутри построено - главное чтоб работало.
28 апр 05, 12:26    [1504776]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Alexey Rovdo
ASCRUS

Гм - а что, на одном компьютере/КПК я уже не могу запустить 2 приложения одновременно - например программу с интерфейсной частью и отчетную систему ?


Однопользовательские <> однозадачные.

С точки зрения БД (и спора КС vs ФС) однопользовательские==однозадачные
ФС имеет смысл использовать только в однопользовательских и однозадачных системах.

Alexey Rovdo
Вы вот опишите, чем в вашем случае КС-система будет отличаться от ФС. И тогда мы поговорим о рациональности КС для такой задачи.


Я не ASCRUS, но я отвечу :)

Чем будет отличаться? Тем, что если запустите две задачи, и одна из них рухнет - то в случае ФС может рухнуть и база (хранилище). И это несмотря на то, что все крутится локально на одном компутере и запущено одним пользователем. Потому как каждое клиентское приложение являет собой и систему управления БД.
В случае же КС, даже урезано-встраиваемого КС - клиентское приложение может вести себя как угодно, если сервер ("серверок") БД живет, то все хорошо.

Это одно из возможных отличий

Если у нас система управления БД размазана по клиентам - имеем ФС.
Если мы ее централизуем каким-либо образом (системные сервисы сваяем, COM-синглетон повесим, апп-сервер прикрутим), и ограничим доступ к данным , чтоб данные были доступны только через эту прослойку - то получим КС.
28 апр 05, 12:47    [1504911]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Alexey Rovdo
ASCRUS

Гм - а что, на одном компьютере/КПК я уже не могу запустить 2 приложения одновременно - например программу с интерфейсной частью и отчетную систему ?


Однопользовательские <> однозадачные.

Вы вот опишите, чем в вашем случае КС-система будет отличаться от ФС. И тогда мы поговорим о рациональности КС для такой задачи.

Большое спасибо ЛП, что за меня ответил. Мне больше добавить нечего.

Alexey Rovdo
ASCRUS

Да что Вы говорите - у меня на КПК уже давно стоит ASA, достаточно эффективно работает с приложениями, написанными на PocketPB и C#, выполняет полноценные SQL запросы, обеспечивает ссылочную целостность и каскады, делает бакупы, через оффлайн репликацию гоняет данные между собой и консолидированной БД, точка доступа к которой обозначена через FTP хоста нашей конторы.


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

ASCRUS

Ну ка сляпайте мне все это на ФС, которые проникают на рынок мобильных устройств, где уже не один год КС РСУБД ASA занимает лидирующие 80% рынка - ну ну ... :)


Плывут пароходы - салют мальчишу! Идут пионэры - салют мальчишу ...

Мы о конкретных продуктах говорим или о КС и ФС архитектурах вообще? Потому как если о продуктах, то и сравнивать надо потребительские характеристики, а не внутреннюю архитектуру. Конечному пользователю глубоко по барабану, как оно там внутри построено - главное чтоб работало.

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

Так что мы только теоризируем или все таки и на практических примерах рассматриваем возможности ФС и КС ?
28 апр 05, 14:02    [1505043]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
Чем будет отличаться? Тем, что если запустите две задачи, и одна из них рухнет - то в случае ФС может рухнуть и


если запустить два мс скл сервера на один файл бд (предположим это возможно) - будет то же самое.

вероятно более правильное отличие одного от другого -

автор
Если у нас система управления БД размазана по клиентам - имеем ФС.
Если мы ее централизуем каким-либо образом (системные сервисы сваяем, COM-синглетон повесим, апп-сервер прикрутим), и ограничим доступ к данным , чтоб данные были доступны только через эту прослойку - то получим КС.


а не то как это называет отдел маркетинга. Если движок сервера встроен в приложение то о какой клиент-серверной архитектуре (физической, логически модули могут быть отдельными как у 1ц на дбф) можно говорить? Это и есть ФС.
28 апр 05, 14:18    [1505112]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
1024
автор
Чем будет отличаться? Тем, что если запустите две задачи, и одна из них рухнет - то в случае ФС может рухнуть и


если запустить два мс скл сервера на один файл бд (предположим это возможно) - будет то же самое.

Разумеется было бы то же самое, если бы это было возможно.
А если бы этих мс скл серверов был сотня, и все бы работали с одним файлом бд, да еще по сети, да еще по ненадежной сети, уродами проложеной - уверяю вас, это было бы совсем печальное зрелище. Потому как по надежности это не отличалось бы от аксеса. Да и по сути - тоже. Была бы обычная файл-серверная база, в которой клиенты почему-то называются sqlservr.exe

-----------------------------------
а что, такое разве возможно??? два сиквела к одной базе цеплять?
28 апр 05, 14:29    [1505170]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ЛП

С точки зрения БД (и спора КС vs ФС) однопользовательские==однозадачные
ФС имеет смысл использовать только в однопользовательских и однозадачных системах.


Какая-то слишком узкая трактовка. Что мешает ФС нормально работать в многопотоковых и многозадачных приложениях? Причем в данном случае речь именно о ФС как об архитектуре, а не о конкретных продуктах.

ЛП

Чем будет отличаться? Тем, что если запустите две задачи, и одна из них рухнет - то в случае ФС может рухнуть и база (хранилище). И это несмотря на то, что все крутится локально на одном компутере и запущено одним пользователем.


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

ЛП

Потому как каждое клиентское приложение являет собой и систему управления БД.


Вот тут не согласен. Каждое "клиентское" приложение использует ФС СУБД, но ей не является. Грубо говоря, разные приложения на одном компе могут одновременно осуществлять обращения к одному API ФС СУБД, реализованному, например, в виде DLL-модуля. Но это вовсе не значит, что при этом каждое приложение будет заново загружать этот модуль в память и инициализировать новый контекст для обработки вызовов (и служебных операций с хранилищем и логами). Другое дело, что некоторые конкретные продукты могут вести себя неадекватно.


To ASCRUS

Говорить то можно и абстрактно, и на примерах. Просто нужно уточнять.
28 апр 05, 14:34    [1505196]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
люди ! почитайте про shared disk cluster, а потом порасуждаем о надежности.
28 апр 05, 14:41    [1505238]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 Alexey Rovdo
Что мешает ФС нормально работать в многопотоковых и многозадачных приложениях?

Ничего не мешает. Если не боитесь пониженной безопасности и надежности - то почему бы и нет. Я - боюсь. Если у меня данные про**утся или украдутся - мне останется тока харакирю сделать.

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

Так это и есть - однозадачная БД
Я что-то не понял - мы спорим о чем-то или в унисон поем?
Я говорю, что ФС имеет смысл использовать только для однозадачных систем, вы вроде как возражаете, но говорите то же самое.

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

Я не говорил, что ФС отрицает использование динамически загружаемых библиотек. Но каждое клиентское приложение, подгружая "ядро" системы управления БД (реализованное как угодно) - использует его по своему усмотрению. Возможно что и неадекватно (напримем в результате сбоя в клиентском приложении).
28 апр 05, 14:46    [1505257]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Yo!!
люди ! почитайте про shared disk cluster, а потом порасуждаем о надежности.

Ну давайте ссылку, почитаем про shared disk cluster на персональных компутерах (рабочих местах секретарш), на КПК, и на всяких там кофеварках (где рулит встраиваемая ASA)
28 апр 05, 14:48    [1505259]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
ЛП
Yo!!
люди ! почитайте про shared disk cluster, а потом порасуждаем о надежности.

Ну давайте ссылку, почитаем про shared disk cluster на персональных компутерах (рабочих местах секретарш), на КПК, и на всяких там кофеварках (где рулит встраиваемая ASA)


на персональных компьютерах, за US$1,665 :)
http://www.oracle.com/technology/pub/articles/hunter_rac10g.html
28 апр 05, 14:55    [1505283]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ASCRUS

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


Ну тут вроде изначально был вопрос именно о будущем. Так вот поясните тогда, какие такие есть причины, по которым в персональные устройства нужно вставлять СУБД с КС архитектурой. Понятно, что ситуация сегодня во многом продиктована банальным отсутствием альтернативы. Но почему она такой должна и остаться? Допустим MS сделает новую версию Foxpro специально для PDA, почему бы ей да и не вытеснить решения Sybase на этой платформе именно ввиду большего соответствия архитектуры системы потребностям приложений?

PS: Да, кстати, у вас получается, что РСУБД и ФС как-то противопоставлены друг другу. Полагаю, что это просто описка и вместо РСУБД вы хотели написать КС СУБД ?
28 апр 05, 15:01    [1505301]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ЛП

Я что-то не понял - мы спорим о чем-то или в унисон поем?
Я говорю, что ФС имеет смысл использовать только для однозадачных систем, вы вроде как возражаете, но говорите то же самое.


Этак мы сейчас запутаемся в нашей трактовке одно- и многозадачности. Давайте так. Я думаю, что ФС удобно использовать в замкнутых (относительно остального мира системах), которые могут быть как одно, так и многопроцессорными. Главное требование - единый пул оперативной памяти, в который по мере надобности и подгружаются все программные модули ФС-системы, и в котором конструируются и совместно используются разными программами структуры данных и буфера, необходимые для работы СУБД.

Сегодня такие условия в основном могут воспроизводиться в разнообразном оборудовании (персональные носимые устройства, коммутаторы, системы контроля и управления приборами, сигнализации и т.п.).
28 апр 05, 15:12    [1505353]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Alexey Rovdo
ЛП

Я что-то не понял - мы спорим о чем-то или в унисон поем?
Я говорю, что ФС имеет смысл использовать только для однозадачных систем, вы вроде как возражаете, но говорите то же самое.


Этак мы сейчас запутаемся в нашей трактовке одно- и многозадачности. Давайте так. Я думаю, что ФС удобно использовать в замкнутых (относительно остального мира системах), которые могут быть как одно, так и многопроцессорными. Главное требование - единый пул оперативной памяти, в который по мере надобности и подгружаются все программные модули ФС-системы, и в котором конструируются и совместно используются разными программами структуры данных и буфера, необходимые для работы СУБД.

Сегодня такие условия в основном могут воспроизводиться в разнообразном оборудовании (персональные носимые устройства, коммутаторы, системы контроля и управления приборами, сигнализации и т.п.).

Ну знаете ... таким образом я могу сейчас сказать, что ASA является замкнутой одно-многопроцессорной системой с единым пулом оперативной памяти (кэшем), где она автоматом подгружает необходимые программные модули (в т.ч. и JVM, если в ходе выполнения работ идут обращения к Java обьектам и ХП), а потом все эти общие структуры данных через стандартные интерфейсы (ODBC, ADO, ADO.NET, JDBC, SOAP ...) совместно используются разными программами и буферами и система является файл-серверной, потому как данные хранит в виде файла на файловой системе ОС. Таким образом, в первую очередь, соблюдая главное условие - единый пул оперативной памяти данных, ASA готова работать в разнообразном оборудовании.

P.S. Я понимаю, что ООСУБД нужно продвигать, но в конце концов для их продвижения начинать нахваливать ФС, чтобы малость подвинуть КС - IMHO не серьезно.
28 апр 05, 15:42    [1505551]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 Yo
Сходил по ссылке, мало что понял :), поэтому задам вопросы здесь.

Связь (тем более выделенный канал) между нодами - это критично или нет?
Ноды обязательно должны знать о существовании других нод?
Что будет, если обе (все) ноды будут нормально функционировать, но соединение между ними разрушится?
Допустима ли ситуация, когда единственно общее место у нескольких нод - это общая дисковая система, и больше никаких точек пересечения?
28 апр 05, 15:42    [1505553]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ASCRUS

Я понимаю, что ООСУБД нужно продвигать, но в конце концов для их продвижения начинать нахваливать ФС, чтобы малость подвинуть КС - IMHO не серьезно.


Вы как-то болезненно относитесь к ООСУБД и во всем видите их незримую тень? Дрожите - они идут!

PS: Представьте себе, я на этом форуме по большей части дурака валяю (в смысле, к рабочим обязанностям это имеет очень далекое отношение), а не занимаюсь продвижением чего бы то ни было. И приплетать в данный топик нашу дискуссию по поводу РСУБД-ООСУБД мне кажется по меньшей мере странным.
28 апр 05, 15:49    [1505595]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ASCRUS

Ну знаете ... таким образом я могу сейчас сказать, что ASA является замкнутой одно-многопроцессорной системой с единым пулом оперативной памяти (кэшем), где она автоматом подгружает необходимые программные модули (в т.ч. и JVM, если в ходе выполнения работ идут обращения к Java обьектам и ХП), а потом все эти общие структуры данных через стандартные интерфейсы (ODBC, ADO, ADO.NET, JDBC, SOAP ...) совместно используются разными программами и буферами и система является файл-серверной, потому как данные хранит в виде файла на файловой системе ОС. Таким образом, в первую очередь, соблюдая главное условие - единый пул оперативной памяти данных, ASA готова работать в разнообразном оборудовании.


Собственно, это лишнее доказательство того, что жесткое разделение на КС и ФС вряд ли возможно. Данная терминология больше применима к сетевым конфигурациям. В рамках же одной системы КС и ФС СУБД отличаются мало (в основном, меньшей навороченностью последних, и, как следствие, их большей производительностью и меньшими требованиями к ресурсам).
28 апр 05, 15:54    [1505622]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Alexey Rovdo
Вы как-то болезненно относитесь к ООСУБД и во всем видите их незримую тень? Дрожите - они идут!

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

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

Alexey Rovdo
Собственно, это лишнее доказательство того, что жесткое разделение на КС и ФС вряд ли возможно. Данная терминология больше применима к сетевым конфигурациям. В рамках же одной системы КС и ФС СУБД отличаются мало (в основном, меньшей навороченностью последних, и, как следствие, их большей производительностью и меньшими требованиями к ресурсам).

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

P.S. Насчет ООСУБД идут - смешно :) Пущай идут мимо, для меня лично ООП для хранения множеств сущностей и связей между ними не представляет какой либо ценности. Однако предположение насчет ООСУБД снимаю, раз уж Вы сами признались, что это не так :)
28 апр 05, 16:22    [1505768]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
ASCRUS

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


Разумеется, вы правы, если все это входит в ваши рабочие обязанности. Я же скорее исследую эти вопросы, чтобы затем переложить эти обязанности на кого-то еще. Но в смысле общего развития местами бывают довольно интересные дискуссии. Правда RSDN мне больше нравится, там публика более спокойная, а потому и обсуждения посодержательней получаются. Но это я отвлекся ...

ASCRUS

Если Вы считаете, что в рамках многопользовательской работы (и без разницы - на одной машине она идет или нескольких) отличий между ФС и КС мало ...


Поменяйте местами "на одной машине" и "многопользовательской". Тогда это действительно будет то, что я считаю.

ASCRUS

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


А вот тут нужны пояснения. Какие такие особенности именно ФС архитектуры несут риски потери или взлома? Полагаю, что вы приведете пример с конкретными продуктами, которые действительно слабо защищены и подвержены рискам. Но это по сути проблема этих продуктов, а не ФС архитектуры в целом.

ASCRUS

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


Все, что вы писали выше будет верным, если принять данное ограничение за определение ФС. Возможно я ошибаюсь, но по-моему это слишком узкая трактовка ФС. Впрочем, настаивать не буду, и если ввести такое ограничение, то в разряд ФС-систем при классификации просто попадет меньше конкретных продуктов.

Я поясню какие все-таки отличия мне здесь видятся.

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

Но, если речь идет о приложениях, работающих на одной машине и имеющих доступ к единому пулу оперативной памяти, то возникает возможность обмена данными не через файл, а через оперативную память (собственно это обеспечивается даже просто в силу буферизации данных средствами ОС). В таком случае информация о блокировках, правах доступа, кэшированные и вспомогательные данные и др. могут использоваться совместно множеством приложений, которые, помимо прочего, и для доступа к этим данным в памяти (или на диске) могут использовать единственную копию программного кода в памяти. При этом сама СУБД по-прежнему может оставаться "несамостоятельной" (не работает как отдельный сервис, не обрабатывает запросы "внутри" этого сервиса и т.п.). К какому класу следует относить такие продукты?
28 апр 05, 17:09    [1505999]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
предлагаю
Guest
недоделанная КС
28 апр 05, 17:20    [1506051]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
2 Alexey Rovdo
Поменяйте местами "на одной машине" и "многопользовательской". Тогда это действительно будет то, что я считаю.

Т.е. вы считаете, что "в рамках работы на одной машине (и без разницы - однопользовательской или многопользовательской) отличий между ФС и КС мало"?
Ну так вы неправильно считаете. Читайте топик с начала.

А вот тут нужны пояснения. Какие такие особенности именно ФС архитектуры несут риски потери или взлома?

Поясняю еще раз. Децентрализованное управление хранилищем и необходимость доступности этого хранилища для всех заинтересованных процессов.

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

Алексей, вы не бредите? Может от Yo заразились?
КАКАЯ РАЗНИЦА ЧТО ИМЕННО ИСПОЛЬЗУЕТСЯ СОВМЕСТНО - КУСОК ПАМЯТИ ИЛИ КУСОК ВСПОМОГАТЕЛЬНОГО ФАЙЛА?
Что от этого меняется?

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

И что, от замены "куска памяти" на "кусок файла" - это утверждение становится неверным?
28 апр 05, 17:39    [1506244]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
2 ЛП

Т.е. вы считаете, что описанный мною последним класс систем следует относить к ФС (и уже с учетом этого и трактовать ваши комментарии)?
28 апр 05, 17:45    [1506285]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Алексей - синстальте себе пожалуйста любого ярко выраженного представителя ФС - DBase, Paradox, Access, FoxPro - погоняйте, посмотрите. Потом уже рассуждайте о пользе и вреде ФС. Я вообще лично не понимаю, о чем Вы говорите. Или дайте подробные пояснения, можно с ссылкой на конкретный продукт и описанием его ФС-особенностей, которые подтверждают все Ваши высказывания.
28 апр 05, 18:06    [1506402]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить