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

Откуда: Харьков, Украина
Сообщений: 62034
2ЛП
не-не-не! я ничего не имею против. Просто приятно, когда наряду с решением перечисляют и слабые стороны, а не выставляются как "лекарство от всех болезней".
1 сен 04, 16:25    [926129]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
не-не-не! я ничего не имею против

Да понял я
Это была превентивная защита от тех, кто прицепится :)
1 сен 04, 16:29    [926154]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Немогу не поддержать, с одной стороны, нападения Зл0го на фаил-серверные технологии. Имел опыт проектирования на Access - радующая скорость разработки, быстро омрачается жуткими тормозами совместного доступа и кошмарными глюками. Ну да бог с ним, давно это было...

То что ФМ позиционируется на рабочие группы от 2 до 250 человек уже о многом говорит. Дай бог сносно на 50 работать будет.
Про какую тут маштабируемость, вообще, можно говорить, не понятно?

Но, судя по всему, все не так плохо. Эта система обзавелась какой-никакой серверной частью -> движется в нужном направлении. Глядишь "завтра" это будет честный клиент-сервер со всеми вытекающими.

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

Ну не хочу я в по жаркой Калифорнии на танке ездить - мне будет жарко, неуютно, горючего нажгу уйму, в узких местах не проеду(не сломав :) ), ни куда не успею и народ распугаю. ЗАЧЕМ?
А вот мотацикл в данном случае подойдет. Ну или машина. Ну уж ни как ни танк!
1 сен 04, 17:32    [926494]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
зря ты такое про эксцесс написал (посмотри на автора предыдущего поста и на того, кто модерит соотв. форум). чувствую, щас начнётся...
1 сен 04, 17:38    [926518]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Dedushka Mazai
Да ладно тебе, не начнется
Я ж тихий псих, не буйный

На такое:
жуткими тормозами совместного доступа и кошмарными глюками

обычно отвечаю "руки кривые" (с127 подтвердит), но за добрые слова в адрес ФС - промолчу
1 сен 04, 17:44    [926555]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
Лох Позорный
обычно отвечаю "руки кривые" (с127 подтвердит)

Что-то я слабо верю, что c127 (адепт Oracle) подтвердит ваши слова по поводу "скорострельности" и надежности Access.
Любой SQL сервер (к Ораклу не ходи :) ) его сделает по обоим пунктам в многопользовательской среде.

Но и Access имеет свою нишу. Плохо, что он не двигается в сторону разделения клиентской и серверной части, как это видно у ФМ. Хотя MS это не нужно - у них для этого есть замечательный продукт MS SQLServer.
1 сен 04, 18:07    [926672]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
теперь точно начнётся...
1 сен 04, 18:10    [926685]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
Опа! уже седьмая ветка. Так, щас подольем.
ЛП, правда али быль, что при каких-то кривых драйверах сетевой карты клиента можно весело повалить базу?

Картинка с другого сайта.
1 сен 04, 18:31    [926762]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>Любой SQL сервер (к Ораклу не ходи :) ) его сделает по обоим пунктам
>в многопользовательской среде.
а вот с этого момента - поподробнее. Никаких дополнительных ограничений накладывать не будем? т.е. просто сервер vs (access or FM)?
1 сен 04, 18:52    [926859]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
ЛП
Guest
2 Leonid
Что-то я слабо верю, что c127 (адепт Oracle) подтвердит ваши слова по поводу "скорострельности" и надежности Access.

с127 подтвердит мои слова по поводу кривых рук

Но и Access имеет свою нишу. Плохо, что он не двигается в сторону разделения клиентской и серверной части

Опять начинается...
Опять рассуждения о том, чего не знаем
Откройте аксес (2000-ой версии и выше), нажмите Ф1, наберите буквы ADP
Если ничего не сумеете найти - воспользуйтесь поиском по форуму.

Любой SQL сервер (к Ораклу не ходи :) ) его сделает по обоим пунктам в многопользовательской среде.

Надежностью меряться не будем (я чё, дурак что-ли), а вот скорострельность - зависит от задач и сервера. Меряться - уже можно.
Тесты связок "DAO + jet + mdb", "DAO+ jet + ODBC + MS SQL", "ADO + OLEDB + MS SQL" для специфических задач когда-то давно проводил, если будет большое желание - можно откопать условия, на которых MS SQL просирал. Количество пользователей правда небольшое было, но и не адын.
Однако давайте в данном топике совсем уж оффтопик устравать не будем? Есть интерес - заводите отдельный топик в этом форуме или в bid=4
Нет интереса - закончим на том, что ваше утверждение было смелым, но неверным.

2 Рыжий Кот
ЛП, правда али быль, что при каких-то кривых драйверах сетевой карты клиента можно весело повалить базу?

Не сталкивался лично. Говорят realtek с родными драйверами - работает не совсем корректно.
По поводу необходимости корректно работающего клиента - я уже писал. Повторить?

автор
Так, щас подольем.

Подливай!
:)
1 сен 04, 19:32    [926931]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
автор
Подливай!
:)

Потерпи до пятницы.

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

автор
По поводу необходимости корректно работающего клиента - я уже писал. Повторить?


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

Картинка с другого сайта.
1 сен 04, 19:54    [926973]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
ЛП
Guest
Потерпи до пятницы.

Не шмогла я, не шмогла...

Хм, если действительно некорректное поведение драйверов может завалить базу, то есть повод любителям Акцеца призадуматься.

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

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

Не понял.

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

А вообще, не такой уж я и фанат файл-серверных систем. Просто работал с ними (аксесовскими) достаточно, чтобы узнать их сильные и слабые стороны, и инстинктивно огрызаться на необоснованные бредовые наезды.
Аксес для меня прежде всего средство разработки, привычное, наверное поэтому и удобное. Пока дотнет не подтянут до его уровня - так и буду на аксесе сидеть.
А по базам мне ближе всего вот такая вот сказка:
https://www.sql.ru/forum/actualthread.aspx?tid=118602&pg=3#925084
1 сен 04, 20:38    [927029]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Я понял очему все ситемы на ФМ которые я видел - редкостные уродцы. Просто ФМ в наших краях гораздо чаще присутствует в job description позиции секретарь-референт, чем в в job description позиции разработчик БД. И вся любоффь-моркоффь. Не видел я пока не одной номальной системы, ни на аксессе, ни на файлмэйкере. Все системы которые я видел представляли собой свалку данных, без первичных/вторичных ключей и нормализации. Зато быстро было сделано, и все усилия потрачены на интерфейс. Вот такой вот экстремальный программинг.

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

Насчет блокировок и таскания файлов по сети поясню примером:
Даны таблицы emloyee(emp_id, dept_id, name...) и department (dept_id, dept_name,...). Требуется вставить запись в employee, так проверяя чтобы dept_id наличествовал в таблице dept. Как это обычно решается в файл-серверных СУБД? Блокировкой таблицы dept? Да тащить ее по сети для того чтобы заблокировать не надо. А вот как мы будем проверять в файл-серверной СУБД тот факт что введенный dept_id присутствует в таблице dept? Если эта проверка происходит на клиенте, значит таблицу с сервера на клиент придется-таки прислать? Или я чего-то не понимаю?

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

Предположим такую простенькую задачку: умножить некую колонку на 10. В Клиент-сервере посылаем с клиента на сервер update my_table set my_value = my_value*10; и быстренько имеем искомый результат. Как ФС будет эту задачу решать рассказать, или сами догадаемся?

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

Сдается мне, что из-за закрытости архитектуры и зловредной идеологии ФМ разработчики просто не понимают что происходит "под капотом". ИМХО очень зря.
1 сен 04, 22:06    [927155]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
locky
>Хотите знать как в ФМ создать масштабирующуюся систему -
>спросите по человечески, лучше на www.fmclub.ru, от этого
>людям больше пользы будет.
если я спрошу на фмклуб - людям ТУТ больше пользы не будет, они то туда не пойдут :-)
тем более топик тут, я тут, спрашивают и отвечают тут...

В систему вводится так называемый Навигатор - одна или несколько доп. таблиц, которые описывают права пользователей и обеспечивают их доступ к другим таблицам. Ввод новых пользователей или таблиц происходит через стандартный интерфейс системы.
1 сен 04, 22:59    [927210]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Злой
Ничего, что я вас еще раз носом в г... тыкну?

А вот как мы будем проверять в файл-серверной СУБД тот факт что введенный dept_id присутствует в таблице dept? Если эта проверка происходит на клиенте, значит таблицу с сервера на клиент придется-таки прислать? Или я чего-то не понимаю?

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

При условии что код занимающийся ими на клиенте, а индексы и таблицы на сервере, что происходит когда мы изменяем данные? Типа блокировки там какие-то, пересылки файлов по сети происходят или как?

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

Расписать по шагам как процесс обновления индекса происходит в файл-серверных СУБД, какие мы имеем race conditions и какие блокировки мы ставим чтобы их избежать?

Если не затруднит - то да, расписать.
Буду вам премного благодарен. Если можно - на примере аксеса.

Предположим такую простенькую задачку: умножить некую колонку на 10. В Клиент-сервере посылаем с клиента на сервер update my_table set my_value = my_value*10; и быстренько имеем искомый результат. Как ФС будет эту задачу решать рассказать, или сами догадаемся?

Да не, не догадаемся
Вы хотите открыть нам америку? Сказать, что если обработка данных происходит на клиенте - то эти данные на этого клиента все-таки придется переслать? А потом еще и обратно?
Спасибо, не надо этого рассказывать. С этим никто не спорит.
Лучше расскажите - что же такого нашли строители в конце 80-ых годов???


З.Ы.
Насчет того что ФС-системы по производительности могут превзойти клиент-сервер (КС), не могут они этого.

С вами спорить я пока не буду. Вы еще из собственного г... не выбрались.
1 сен 04, 23:06    [927217]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Gluk (Kazan)
Как с этим у FM (в смысле кроме холодного физического бакапа у него чего нибудь есть) ?

Горячий бакап.

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

Вам - тошнить не нужно, ФМ7 - это КС.

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

А вот Вы - нате, подавитесь!

FileMaker Server 7: Optionally perform maintenance on live databases, including live backups while the file is in use.

Сами виноваты. ПотщателнЕЕ предыдущие постинги читать нужно было. Будете теперь ходить как лох - в галстуке и без булавки... да ещё и на металлоискателях позвякивать.
1 сен 04, 23:15    [927225]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
ФМ в наших краях гораздо чаще присутствует в job description позиции секретарь-референт, чем в в job description позиции разработчик БД. И вся любоффь-моркоффь. Не видел я пока не одной номальной системы, ни на аксессе, ни на файлмэйкере.

Побольше консерватизма и упертости - и в Ваших краях они никогда не появятся.
1 сен 04, 23:29    [927229]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Побольше консерватизма и упертости - и в Ваших краях они никогда не появятся.

!!!
:)
1 сен 04, 23:36    [927231]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Согласен
Guest
Александр Зуев
locky
>Хотите знать как в ФМ создать масштабирующуюся систему -
>спросите по человечески, лучше на www.fmclub.ru, от этого
>людям больше пользы будет.
если я спрошу на фмклуб - людям ТУТ больше пользы не будет, они то туда не пойдут :-)
тем более топик тут, я тут, спрашивают и отвечают тут...

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


Это не масштабируемость, извините. Это раздача прав. Не больше, не меньше. Тоже важная вещь. Но не масштабируемость.
И потом, если для ФМ интерфейс первичен, а структура БД вторична (как я понял) то какой смысл в раздаче прав на таблицы БД ?
1 сен 04, 23:48    [927236]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Gluk (Kazan)
Более всего прибивают тезисы со стороны адептов FM о новых методологиях проектирования ПО (начиная с кнопочек).


locky
быть может, резкая критика ФМ - результат высказываний адепта ФМ в стиле "опытный проектировщик ФМ рисует формочки и кнопки - и получает структуру базы".


Всё очень просто, в системах, которые Вы разрабатываете не уделяется никакого внимания интерфейсу пользователя. Вы сначала разрабатываете структуру, а потом навешиваете на неё какой-нибудь серенький интерфейсец. Товарного вида Ваши системы не имеют, но работают быстро и устойчиво. В системах, которые я разрабатываю интерфейсу уделяется очень большое внимание, поэтому мне приходится продумывать интерфейс и структуру одновременно.
2 сен 04, 00:02    [927244]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Согласен
Это не масштабируемость, извините. Это раздача прав.

Добавляем новых пользователей - получаем масштабируемость по одному направлению. Никаких настроек на сервере или на компьютерах вновьприбывших пользователей при этом делать не требуется. Добавляем новые таблицы - получаем масштабируемость по второму направлению. Какие ещё направления Вас интересуют?

для ФМ интерфейс первичен, а структура БД вторична (как я понял)

Нет, для ФМ интерфейс важен. Так уж повелось, что ведущие разработчики ФМ соревнуются друг с другом в качестве интерфейса. На одном интерфейсном решении разрабатывается не более 3-5 систем. Но интерфейс разрабатывается к БД, для неё, и во имя неё, поэтому термин "вторична", в данном случае звучит как-то странно.
2 сен 04, 00:15    [927248]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Ха-ха. Насчет индексов в ФС СУБД - это была чисто конкретная подстава с моей стороны, уж извините. Конечно я знаю что по вторичным ключам можно (и нужно) строить индекс, в клиент-серверныз СУБД так же как и в файл-серверных. Только вот это как раз и есть пример наглядно иллюстрирующий необходимость продумывания не только логической но и физической структуры данных. Что при файлмэйкерном подходе к разработке судя по всему не происходит (см. выше). Усилия-то идут на отрисовку интерфейса, насколько я понял "идеологию" файлмэйкерной разработки.

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

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

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

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

Хотелось бы узнать что есть "горячий бэкап" в терминологии файлмэйкера. То есть, конкретно, что происходит если мы одновременно вносим изменения в данные и пытаемся их бэкапить? Подсказываю что мы можем менять данные в более чем одной таблице, и более чем одной записи, и в промежутке они могут обрабатываться в приложении. Умеет ФМ создавать "point in time consistent snapshot" ? Запишутся в бэкап данные как они были на момент начала бэкапа или уже измененные данные? Очень интересно было бы узнать механизм энтовго горячего бэкапа. Может имя этого механизма - "грязное чтение"?
2 сен 04, 04:27    [927294]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Александр Зуев
Gluk (Kazan)
Более всего прибивают тезисы со стороны адептов FM о новых методологиях проектирования ПО (начиная с кнопочек).


locky
быть может, резкая критика ФМ - результат высказываний адепта ФМ в стиле "опытный проектировщик ФМ рисует формочки и кнопки - и получает структуру базы".


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


А Вы видели мои системы чтобы так заявлять ? Вот уже лет 10 я уделяю МАКСИМАЛЬНОЕ внимание именно пользовательскому интерфейсу и добился в этом определенных успехов. В общем Вы меня сильно разочаровываете своими НЕОБОСНОВАННЫМИ высказываниями.

По поводу горячего бакапа: расскажите что Вы под этим понимаете и как это реализуется в FM. Просто сказать hot backup и дурак может.

Я думаю, всем будет интересно.
2 сен 04, 08:00    [927391]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1815
Зл0й

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

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

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

Поэтому "создавать отдельный файл для блокировок - ни к чему хорошему не приводит", нет конечно это лучше чем блокировать всё хранилище, и в случае слабой нагрузки решение которое "в принципе работает" и может быть вполне удовлетворительным, но давайте не придераться к словам, конечно ведро дерьма лучше чем бочка дерьма, но оно всё еще не достаточно хорошо ;).
2 сен 04, 11:17    [928236]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
как уже говориль Глюк - а Вы наши интерфейсы видели? нет? дык о чем разговор?
Более того, интерфейс есть не более чем средство отображения и первичного ввода информации, которое можно сделать каким угодно - это не принципиально. а вот структуры данных - это да..., это базис! с хренововыми структурами вы ни в жисть не "слабаете" нормальное приложение. Хотя... Нет, никаких "хотя".
Немаловажным также является унификация интерфейса. как я уже говорил, у мен более 300 справочников. я буду учить юзеров работать с каждым из них? сил у меня не хватит на это. Поэтому я предпочту усредненный интерфейс. да, он не всегда наиоболее удобен. Но в 95% случаев - вполне адекватен.

Теперь по поводу безопасности с ФС... Дык нету её... если есть, не затруднит ли Вас описать её механизмы?
2 сен 04, 12:08    [928665]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить