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

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

Алексей - синстальте себе пожалуйста любого ярко выраженного представителя ФС - DBase, Paradox, Access, FoxPro - погоняйте, посмотрите. Потом уже рассуждайте о пользе и вреде ФС. Я вообще лично не понимаю, о чем Вы говорите. Или дайте подробные пояснения, можно с ссылкой на конкретный продукт и описанием его ФС-особенностей, которые подтверждают все Ваши высказывания.


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

В соседней ветке о сравнении SQL и DBF показано много недостатков названных вами продуктов и ФС-архитектуры вообще. Совершенно очевидно, что развитие может пойти именно по пути устранения этих недостатков. Понятно, что классические КС решают проблемы в корне. Но ведь возможно и такое решение, которое описал я. Т.е. возможно появление продуктов, которорые трудно отнести к классическим КС, но классическими ФС они уже не являются.

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

Выше я уже говорил, что не хочу сводить обсуждение в данной ветке к очередному сравнению ООСУБД и РСУБД. Поэтому FastObjects я здесь привел именно как пример определенного класа продуктов, с классификацией которых имеются затруднения. Но ведь недостатки названных вами ФС очевидны для многих, поэтому их дальнейшее развитие может существенно расширить набор таких "непонятных" продуктов. Что бы вы сказали на этот счет?
28 апр 05, 19:32    [1506658]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Cat2

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

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

Откуда: МО Электросталь
Сообщений: 5994
Alexey Rovdo
В соседней ветке о сравнении SQL и DBF показано много недостатков названных вами продуктов и ФС-архитектуры вообще. Совершенно очевидно, что развитие может пойти именно по пути устранения этих недостатков. Понятно, что классические КС решают проблемы в корне. Но ведь возможно и такое решение, которое описал я. Т.е. возможно появление продуктов, которорые трудно отнести к классическим КС, но классическими ФС они уже не являются.

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

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

За дисскусией я следил и мне кажется, что FastObjects в данном случае является больше неким интеллектуальным интерфейсом между хранилищем данных и клиентской частью, чем КС или ФС. Мысль исходит из того, что если я правильно понял, то работать он может как с "внешними" релляционными серверами, так и заточенные под нужды хранения обьектов специализированные хранилища данных. Таким образом, я не удивлюсь, если при небольшой настойчивости, желании и хороших знаниях, его можно будет настроить хранить обьекты не в хранилище данных, а прямо в виде файлов. Конечно может я не правильно понял, но впечатление сложилось именно такое.

Что же касается будующего - мне кажется будующее не за КС или ФС, а просто за СC (сервер БД+сервер приложений, тесно интегрированные вместе). Если убрать теоризирование и порыться в практическом опыте, то наиболее удачные из других систем в прошлом были Access и FoxPro. Почему ? Потому что они являли собой единую среду управления данными и их визуализацией, что давало существенную скорость при разработке и дополнительные фичи. Пересев на КС я получил с одной стороны черный мощный ящик управления данными, с другой написанное на другой платформе/языке клиентское приложение, соединенное между собой через универсальный провайдер доступа к данным (тот же ODBC). Лично я считаю, что стоимость разработки и сопровождения систем тут на КС существенно возросла. Чтобы снизить эту стоимость я перешел на РСУБД с максимально удовлетворяющей для разработки моих задач функциональностью (в данном случае это ASA) и фактически перенес всю бизнес-логику проектов в БД. В принципе это существенно снизило затраты, несмотря на то, что в РСУБД используются процедурные языки, наличие мощного языка запросов для обработки множеств привело к сокращению размера кода к аналогичному, реализованному на тех же ООП языках, использование шаблонов позволило решить проблему повторного использования кода в БД без потери производительности, динамический SQL дал мне в руки фактически собственный язык в приложения, на котором можно динамически изменять не только условия выполнения бизнес-логики, но и сами ее алгоритмы, вплоть до организации поддержки их версионности во времени или других измерениях. Клиент же стал супер-тонким - фактически это просто GUI оболочка, задача которой красиво показать, дать изменить и выдать в виде отчета информацию. Однако даже не смотря на это, любое изменение структуры БД, которое элементарно при достаточно граммотном проектировании БД производится без потери работоспособности БД, частенько приводит к потере работоспособности клиентского приложения и требованию к его модификации.

Например, мне сильно в существующих ООП языках, используемых для построения клиентких приложений, не нравится их строгая типизация, будь то Delphi, C#, PowerBuilder или C++. Выкручиваться везде можно по разному, но все равно это является выкручиванием, хотелось бы в клиентском приложении видеть тесное сотрудничество с метаструктурой БД, где любое изменение ее сущностей или доменов автоматически отображается на клиентское приложение, а сами формы, отчеты и код хранились так же в БД, как это удачно сделано в Access и их хранение в РСУБД предоставило бы кучу дополнительных и удачных возможностей по управлению визуализацией GUI.

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

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

Все это сейчас наполовину есть у меня в ASA - макеты HTML форм и отчетные формы на FastReport я спокойно храню прямо в БД, WatcomSQL достаточно мощный язык для программирования логики, который ко всему прочему как язык хранимых процедур спокойно напрямую выполняет запросы и осуществляет навигацию, веб-сервисы позволяют принимать, обрабатывать и возвращать запросы через HTML, XML и SOAP. Однако HTML не самый лучший, удобный и очень трудозатратный способ организации GUI, WatcomSQL не ООП, а FastReport вообще отдельный продукт - соотвествующе интранет сайтики мы делаем, но только для внутренних нужд и не более, хотя делается это на ХП WatcomSQL с космической скоростью и элементарно сопровождается.

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

Ну естественно все это из разряда, пофантазировать перед сном, каждому будующее кажется своим желанным горизонтом мечты :)
29 апр 05, 00:23    [1507031]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Люблю ФС
Guest
1 оптимистическая буфферизация
2 действия по удалению, вставке, обновлению данных в таблицах
3 начать транзакцию
4 скинуть все изменения в таблицы
5 закончить транзакция

разве в этом случае при потере сети или лепестричества ФС ляжет???
У меня не ложится, наверное я все неверно делаю... аль как???

(конечно в КС вероятно ничего такого не надо делать.. просто подключить микрофон и сказать "прошу вставить в накладную товар такой-то и закоммитить..."
не знаю не пользовался...)
29 апр 05, 11:01    [1507689]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
Люблю ФС
1 оптимистическая буфферизация
2 действия по удалению, вставке, обновлению данных в таблицах
3 начать транзакцию
4 скинуть все изменения в таблицы
5 закончить транзакция

разве в этом случае при потере сети или лепестричества ФС ляжет???
У меня не ложится, наверное я все неверно делаю... аль как???

Про транзакции поподробнее можно?
29 апр 05, 11:08    [1507718]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Люблю ФС
1 оптимистическая буфферизация
2 действия по удалению, вставке, обновлению данных в таблицах
3 начать транзакцию
4 скинуть все изменения в таблицы
5 закончить транзакция

разве в этом случае при потере сети или лепестричества ФС ляжет???
У меня не ложится, наверное я все неверно делаю... аль как???

(конечно в КС вероятно ничего такого не надо делать.. просто подключить микрофон и сказать "прошу вставить в накладную товар такой-то и закоммитить..."
не знаю не пользовался...)

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

И кстати на пункте 5 в КС системах не заканчивается работа, как минимум идет работа с лог-файлом и CHECKPOINT, без которых невозможна максимальная гарантия того, что при падении сервера БД в любом месте его работы, будет содержать достаточно информации для того, чтобы откатиться до последнего стабильного состояния.

P.S. Кстати вот подумалось, что управление транзакциями и блокировками, автоматическими откатами, контроль заданных условий, логирование операций, обеспечение интегрированной системы прав доступа - это все таки в принципе ярко выраженные черты КС систем. Однако большинством из перечисленного MySQL не обладает (пока игнорируем его новую версию). Тогда кто он больше получается ? Если считать с точки зрения условия, что любой доступ к данным осуществляется только через сервер - то вроде как он КС. С другой стороны не имея всего вышеперечисленного, он по ближе смотрится к ФС. С другой стороны Access, который обладает почти всем вышеперечисленным, не является КС в силу отсутствия выделенного сервера. В итоге для небольшого проекта, лично я бы выбрал ФС Access чем КС MySQL :)
29 апр 05, 11:45    [1507896]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Люблю ФС
Guest
Пожалуйста!

мои команды по модификации записей
Delete FROM.....
INSERT INTO......
UPDATE.....

BEGIN TRANSACTION
IF m.llSuccess = .T.
llSuccess = TableUpdate(.T.,m.llIsOtherWrite,'Таблица1')
ENDIF
............................................
IF m.llSuccess = .T.
llSuccess = TableUpdate(.T.,m.llIsOtherWrite,'Таблица ЭН')
ENDIF

IF m.llSuccess = .F.
* ошибка мля!!!!!
ROLLBACK
* анализ ошибки
ELSE
END TRANSACTION
ENDIF
29 апр 05, 11:49    [1507924]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Люблю ФС
Guest
ASCRUS

Итак посередине пункта 4 у нас пропала сеть. Возникает закономерный вопрос - кто будет откатывать транзакцию, если ее владелец (он же по совместительству сервер) ушел в небытье


если честно есть идея там поставить мессаджбокс и выдернуть сетевой шнур.. освобожуть попробую.. но я сдела как?
после начала транзакции = обработчик ошибок, который в случае ЛЮБОЙ ошибки делает РОЛЛБЭК!!!!!
(почему это сделал.. а потому, что в процессе написания бывало ну ошибку сделал в самом операторе модификации.. в итоге получал открытые транзакции... с таким обработчиком получилось = "ошибка в транзакции" = откат...)
Ведь в ФС обработка-то идет не на сервере, который мог уйти на небо а у мена на клиенте.. откат тоже ж у меня произойдет, конечно вероятно есть спорные моменты, но натолкнуться на них еще не пришлось..
Конечно это не есть критерий...
однако не станете же Вы говорить, что у поклонников КС сервера постоянно падают?
29 апр 05, 12:02    [1507994]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
2Люблю ФС

ну и кто у тебя ролбэк выполнит :) клиент без шнура питания ?
29 апр 05, 12:12    [1508045]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
к стате если у аксеса блокировки в файлике хранятся получается если клиент отвалился то блокировки там останутся навсегда ??
29 апр 05, 12:14    [1508056]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

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

Итак посередине пункта 4 у нас пропала сеть. Возникает закономерный вопрос - кто будет откатывать транзакцию, если ее владелец (он же по совместительству сервер) ушел в небытье


если честно есть идея там поставить мессаджбокс и выдернуть сетевой шнур.. освобожуть попробую.. но я сдела как?
после начала транзакции = обработчик ошибок, который в случае ЛЮБОЙ ошибки делает РОЛЛБЭК!!!!!
(почему это сделал.. а потому, что в процессе написания бывало ну ошибку сделал в самом операторе модификации.. в итоге получал открытые транзакции... с таким обработчиком получилось = "ошибка в транзакции" = откат...)
Ведь в ФС обработка-то идет не на сервере, который мог уйти на небо а у мена на клиенте.. откат тоже ж у меня произойдет, конечно вероятно есть спорные моменты, но натолкнуться на них еще не пришлось..
Конечно это не есть критерий...
однако не станете же Вы говорить, что у поклонников КС сервера постоянно падают?

Данные лежат у нас на другом сервере. Где именно Вы собираетесь выполнять ROLLBACK, когда вышла "ошибка мля" о потере сетевого соединения - на своей машине с эмпирическим откатом данных на удаленном, но уже недоступном для Вашего кода сервере что ли ? :) А давайте усложним ситуацию и не сетевой шнур выдернем из клиентских машин, а во время транзакции будет производить достаточно большое кол-во операций изменения данных и подойдем к серверу и нажмем RESET. Что произойдет в случае КС ? После перезагрузки сервера РСУБД во время старта БД автоматически обнаружит критическое завершение работы и полностью откатит ее состояние до последнего стабильного состояния (то есть откатит все не законченные транзакции и запишет в БД все подтвержденные транзакции, если они еще туда не успели записаться). В ФС кто этим всем будет заниматься ? Первое приложение, которое подцепилось к БД ? Лично я себе не очень представляю решение этих проблем на ФС. Какая то анархия получается - вместо того, чтобы централизованно управлять данными, с ними играются все кому не лень.
29 апр 05, 12:19    [1508084]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
P.S. Кстати приведенный в примере код написан на чем - VFP или я ошибаюсь ?
29 апр 05, 12:20    [1508091]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Люблю ФС
Guest
Yo!!
2Люблю ФС

ну и кто у тебя ролбэк выполнит :) клиент без шнура питания ?


не придирайтесь.. я ж сказал - будет время специально выдерну шнур и погляжу.. если откат произойдет, то увы поям=снить КТО его выполнил не смогу... но факт будет..
а код = ВФП = верно.....

Я же поделился соображением "у меня не падало никогда...."
сервак на упсах.. клиент тоже.. если Вы пользуетесь доррогими серверами и у Вас нету защиты от пропажи сети или питания - ФС тут при чем?
но, судя по нику ЙО! Вы просто любитель пофлеймить....
29 апр 05, 12:28    [1508125]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
будет не факт, а fuck :) но если увидете откат советую сеачало сходить к глазному, а потом сразу в Стокгольм за Нобелевской премией за открытие доброй феи ;)
29 апр 05, 12:42    [1508184]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
tygra
Member

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

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

Это называется TAXXI
Я так понял, технология или умерла, или производитель умер а дело его живет... Не понятно.
Но я пробовал еще в 1998 году - потрясающая вещь была тогда, как сейчас - не знаю. Это даже не терминал - просто клиентское приложение рисуется (графически) на клиенте, а исполняется на сервере. Прикольно.

-- Tygra's --
29 апр 05, 13:33    [1508417]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
А вообще, есть будущее у ФС, есть!
Я сам видел: приятный свет в конце тунеля... И еще ФС мне оттуда погудел: туууу тууууу...

-- Tygra's --
29 апр 05, 14:16    [1508614]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
Люблю ФС
не придирайтесь.. я ж сказал - будет время специально выдерну шнур и погляжу..

Будет "Нераспознаваемый формат БД"

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

Пользуемся. И защита есть. И сеть классная. А "Нераспознаваемый формат БД" пару раз в неделю тут как тут.
29 апр 05, 14:19    [1508627]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
блин, ну понаписали (маразматики )

Пытаюсь на пальцах объяснить, как механизм транзакций реализован в аксесе
2 ASCRUS
Итак посередине пункта 4 у нас пропала сеть. Возникает закономерный вопрос - кто будет откатывать транзакцию, если ее владелец (он же по совместительству сервер) ушел в небытье ?

После начала транзакции и до коммита - все измененные данные хранятся на клиенте. В основной базе изменений еще нет. Там только блокировки на запись для измененных данных.
Соответственно, если до коммита клиент отвалится - откатывать в основной базе в общем-то и нечего. Клиент отваливается и уносит с собой в могилу все свои изменения.
На вопрос "кто будет откатывать то, чего нет" - ответ получен?

Ну а в момент коммита изменения шлются на сервер, причем не сразу пишутся в основные таблицы, а в новые страницы данных. Когда все переслалось - изменяемые страницы блокируются для чтения/записи, база на короткое время переводится в состояние "Suspect", в метаданных заменяются указатели на актуальные страницы, база выводится из состояния Suspect.
Действие по идее должно быть атомарным - один указатель на старый "массив" ссылок на актуальные страницы заменяется другим указателем, на обновленный "массив" ссылок на страницы. Это по идее. Как оно на самом деле - с ходу не скажу.
Собственно имеется один промежуток времени, в течении которого отвал клиента критичен - от включения Suspect-состояния базы до его выключения. При отвале клиента в этом промежутке - получим любимый "нераспознаваемый формат базы, требуется восстановление". Однако длительность этого критичного промежутка всеми возможными средствами минимизирована.

Все что написано - это очень грубо и приблизительно. Но, надеюсь, общий смысл понятен.

----------------------------

2 Yo
к стате если у аксеса блокировки в файлике хранятся получается если клиент отвалился то блокировки там останутся навсегда ??

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

----------------------

2 f_w_p
автор
Пользуемся. И защита есть. И сеть классная. А "Нераспознаваемый формат БД" пару раз в неделю тут как тут.

Ну... Ты наверное догадываешься, что я сейчас скажу :)
Руки кривые. Потому и база падает.
А если до сих пор этим пользуетесь несмотря на то, что падает раз в неделю, то у кого-то (не факт что у криворукого разработчика) - и с головой не все в порядке.
29 апр 05, 15:22    [1508851]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Alexey Rovdo
Member

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

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


Хмм...
А почему бы и нет - первое приложение, которое подцепилось к БД.

Залезет в лог, посмотрит соответствие лога текущему состоянию хранилища и, если надо, внесет все поправки (снимет прошлые блокировки и т.п.). Схема то действий та же, что и в КС.
29 апр 05, 15:36    [1508889]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Yo!!
Guest
>После начала транзакции и до коммита - все измененные данные хранятся на клиенте. В основной базе изменений еще нет.

не понял, вся база копируется на клиент ? я делаю
begin tran
update mytabe set bablo=bablo+20 ;
update mytabe2 set bablo=bablo+40 ;
update mytabe2 set bablo=bablo+10 ;
можно поподробней что и где меняется ?


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

так что из .ldb прописанные блокировки исчезают магическим путем ? кто в нем зачищает после отвалившегося клиента ??
29 апр 05, 15:42    [1508916]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Alexey Rovdo
ASCRUS

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


Хмм...
А почему бы и нет - первое приложение, которое подцепилось к БД.

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

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

Но ведь не будешь работу всех пользователей прекращать только из-за того, что кто-то одни не успел Commit сказать? Незаконченная транзакция не повод для паники.
29 апр 05, 15:43    [1508921]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
Люблю ФС
Guest
Эх не хочу Выражаться, но извините, те, кто меня пытался убедить в моих ошибках...
код транзакции я привел? привел
так вот... под вашим давлением провел я опыт...
поставил после
Begin trans
wait window 'transaction is started...'

Теперь следите за моим движением :-)

Редактирую запись
нажимаю кнопку сохранить, под которой собственно этот код
появляется окошко 'transaction is started...'
кто знает фокс поймет....

(да не упомянул саму БД поместил на сервак)
не ленюсь наклоняюсь вытягиваю шнур сетевой из машины.. то есть сети нету... проверил!!!
нажимаю пробел (любую клавишу!!!!)

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

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

Так что Уважаемые оппоненты, нечего на зеркало пенять!!!!!

К сообщению приложен файл. Размер - 0Kb
29 апр 05, 15:52    [1508959]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
Yo!!
>После начала транзакции и до коммита - все измененные данные хранятся на клиенте. В основной базе изменений еще нет.

не понял, вся база копируется на клиент ? я делаю
begin tran
update mytabe set bablo=bablo+20 ;
update mytabe2 set bablo=bablo+40 ;
update mytabe2 set bablo=bablo+10 ;
можно поподробней что и где меняется ?

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

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

так что из .ldb прописанные блокировки исчезают магическим путем ? кто в нем зачищает после отвалившегося клиента ??

А они там кому-то мешают? Есть отметка о том, что запись заблокирована. При наличии такой отметки - проверяется ее валидность (обращением к предположительно залоченному средствами файловой системы куску файла). Не валидна - можно и убить ее нафиг. При желании можно убить и все остальные блокировки от отвалившегося клиента, чтобы при следующих обращениях клиенты не утруждали себя лишними проверками. Как именно ведет себя аксес - точно не скажу.
29 апр 05, 15:56    [1508981]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Люблю ФС

Зачем терять время на такие примитивные опыты ? Сделайте старт транзакции, в коде поменяйте в табличке (и чтобы в ней индексы были обязательно), хотя бы с 100 записей, добавьте 100 и удалите существующих 100. Потом сделайте свое окошко, выдерните шнур и заново соединив сеть посмотрите - осталась ли табличка нетронутой, как будто бы мы не меняли, удаляли и добавляли записи. О результатах доложите пожалуйста, интересно, как VFP справится с такой задачей.
29 апр 05, 16:00    [1509000]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли будущее у файл-сервера?  [new]
ЛП
Guest
ASCRUS
автор
Люблю ФС

Зачем терять время на такие примитивные опыты ? Сделайте старт транзакции, в коде поменяйте в табличке (и чтобы в ней индексы были обязательно), хотя бы с 100 записей, добавьте 100 и удалите существующих 100. Потом сделайте свое окошко, выдерните шнур и заново соединив сеть посмотрите - осталась ли табличка нетронутой, как будто бы мы не меняли, удаляли и добавляли записи. О результатах доложите пожалуйста, интересно, как VFP справится с такой задачей.

Аксес справится нормально.
Никакие записи не изменятся, не добавятся, не удалятся, база не обрушится, мертвых блокировок не останется.
А как фокспро с этим справится - хз.
29 апр 05, 16:04    [1509016]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить