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

Откуда: Северная Калифорния
Сообщений: 686
ИМХО ПОДходящее это когда исключена возможность грязных данных. Соответственно СУБД не поддерживающая ограничения целостности не относится к классу ПОДходящих по определению, для многопользовательских систем. Для систем где один юзер монопольно владеет всеми данными можно вообще обойтись без СУБД. Хотя, если в перспективе 2 и более юзера, тогда лучше с ней.

Насчет сжатых сроков и требований заказчика хорощо сказано. Если заказчик - "лох позорный" и не поставил требований по чистоте данных, возможности их восстановления итп, тогда давай, обувай его. "Без лоха - жизнь плоха". Быстренько нарисовал формочек, отчетиков, бабки вырубил и довольный свалил. Пусть дальше клиент сам умирает с этой хреновиной, или бабки платит за доводку продолжающуюся вечно. Такой подход у меня уважения не вызывает. Хотя, кушать хочется, могу посочувствовать. Я видел не одну систему разработанную с помощью RAD, и не две. Много я таких уродцев повидал, во всех видах видал. Как правило задача ставилась в таком ключе: "выяснить как "оно" работает, задокументировать, написать нормальную спецификацию, и реализовать по-нормальному". Клиенту это стоило от 120 долларов в час. Было бы горздо дешевле делать "как следует" с самого начала. Как правило клиенту кто-то разработал быстро-дешево, а потом клиент заплакал горькими слезами. Далее или вбухивают в "доводку" больше чем было потрачено на собственно разработку и потом все равно переделывают, или начинают "переделывать" вскоре после того как сталкиваются с первыми проблемами. Все зависит от того насколько быстро клиент "фишку просечет".

Все вышеизложенное - для систем с более чем одним юзером. Для одного юзера Файлмэйкер и Аксесс вполне канают. Как только юзеров более одного - все выбросить и переписать.
31 авг 04, 00:56    [919874]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Александр Зуев, бросайте этот ФМ. Вы конечно к совету не прислушаетесь, но неправильно всё это. И самое плохое что Вы думаете что это правильно. Потом Вы это поймёте. Обосновывать не буду - Вы всё равно останитесь при своём мнении(я бы тоже остался).
За информацию спасибо, представление о продукте получил, буду избегать

Кстати у меня эта базы занимает меньше 100М, поиск естественно делается мгновенно(т.е. сравнимо с временем нажатия на клавишу). Ну и дополнительные возможности всякие еще сделаны, типа адрес надо писать "Мурманская область, г. Мурманск", а юзер пишет только Мурманск и ему выдаются варианты регионов где этот город(или посёлок, улица) может быть.
31 авг 04, 01:09    [919877]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
c127
Guest
2 Зл0й

Хорошо излагаешь. Уважаю.
31 авг 04, 04:09    [919909]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Злой
Вся фишка в том, что наш код на SQL с этими указателями не работает, поэтому он независим от физической организации данных на диске. Имеем урок
- Код приложения не должен напрямую оперировать физическими структурами данных на диске
- Между приложением и СУБД должен быть API
Те кто усвоили этот урок еще в 80х годах прошлого века в конце концов и пришли к современным 2х-3х и более звенным системам клиент-сервер.

Все-таки такое ощущение, что товарисч Злой знает о файл-серверах только понаслышке.
Товарисч Злой, вы что, действительно думаете, что в файл-серверных системах SQL-запросы выглядят следующим образом:
Select 100байт
From пятыйсектортретийблинвтороговинта
Where смещениеотначалафайла=500байт
Order By номердорожки
Не знаю, какие книжки вы читаете на ночь, но вам лучше эти книжки выкинуть, ибо они пагубно влияют на вашу неокрепшую детскую психику.
Лучше перескажите форуму сказку про Буратино. История деревянного мальчика более похожа на правду, нежели ваши рассуждения о ФС, в которых ни блокировок, ни связей, ни транзакций, ни возможности работать более чем одному пользователю, и т.д., и т.п. Раньше вы не могли ссылочную целостность сделать, теперь споткнулись на простейшем механизме типа вторичного ключа

Не любите ФС - ваше право, можете даже других агитировать. Но качество аргументации должно быть повыше (с) IgorM

З. Ы. Насчет грязных данных, аномалий, логики в приложении и т.п. - согласен целиком и полностью. Однако разруха - она в головах. Клиент-серверные технологии не избавят вас от дурака-программиста. У него нет ни опыта, ни времени, а есть только какой-нибудь Oracle (MS SQL, DB2, etc.) и негнущиеся пальцы.
"Какая такая точность вычислений? Это же ОРАКЛ!!!" (с) Victosha

З.З.Ы. А чего это я вообще в топике про неизвестный мне файлмейкер делаю? Ухожу, ухожу, ухожу...
31 авг 04, 10:16    [920283]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
DimaR
Member

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

Давай еще,
может ктото из файлсерферов проникнится.
31 авг 04, 10:41    [920390]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
Знаем мы про файл-мэйкер сервер. Даже работали с ним. Это и есть тот самый "рудиментарный" сервер

А откуда у Вас такие данные? Дело в том, что FileMaker Server 7 вышел только недавно, его ещё и обкатать-то толком не успели, да к тому же сетевые протоколы и пр. - закрытая информация. Я, при всем своем опыте работы на ФМ, не рискну делать подобных заявлений. А Вы на основании каких источников их делаете? и каковы критерии оценки/сравнения?
31 авг 04, 12:02    [920811]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
alfer_fm
Member

Откуда: Россия, Москва
Сообщений: 33
Александр Зуев
Зл0й
Знаем мы про файл-мэйкер сервер. Даже работали с ним. Это и есть тот самый "рудиментарный" сервер

А откуда у Вас такие данные? Дело в том, что FileMaker Server 7 вышел только недавно, его ещё и обкатать-то толком не успели, да к тому же сетевые протоколы и пр. - закрытая информация. Я, при всем своем опыте работы на ФМ, не рискну делать подобных заявлений. А Вы на основании каких источников их делаете? и каковы критерии оценки/сравнения?


Небось нелицензионный ;) :)
31 авг 04, 12:07    [920834]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
Filemaker и ему подобные продукты, вкупе с родстенной им идеологией разработки приводят вот к чему:
- вся логика на клиенте
- структура данных толком не продумана, ни логическая ни физическая
- надежных механизмов обеспечения целостности данных нет

Откуда имеем:
- грязные данные
- трудноповторимые а потому трудноустранимые ошибки в системе

Это - бред сивой кобылы. Думаю не ошибусь, если скажу что Вы, господин ЗлОй, сами ни одной системы на ФМ не разработали. Ни одной моей разработки на ФМ Вы точно в глаза не видели. Так по какому праву Вы утверждаете что мои системы заведомо содержат "грязные данные" и ошибки?


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

Возможно, но какое это имеет отношение к ФМ? В ФМ можно реализовать любые "constraints"!


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

Очередная глупость. Методология RAD не предполагает разработку только однопользовательских систем. А возможнось разработки в ФМ однопользовательских систем, не означает что в ФМ можно разрабатывать только однопользовательские системы. Я, к примеру, вообще не занимаюсь разработками однопользовательских систем. А насчет того, у кого на что опыта хватает - ведите себя поприличнее п-ста.


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

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


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

- Наглое и лживое утверждение.


Поэтому я считаю что разработка решений на основе Access, Filemaker и им подобных продуктов - мероприятие в долгосрочной перспективе непрактичное, для многопользовательских систем. Какова будет цена маленькой "ошибочки" в данных если вместо изделия №25 будет №26?

Мне такое и в страшном сне не приснится. А Вам похоже досконально известно откуда такая ошибка может появиться в ФМ. Нельзя ли пошагово расписать алгоритм её появления?


А что будет если наша доблестная система "грохнется" из-за отказа железяки?

Тоже самое, что и при падении любой системы - восстановление с бакапа.


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

Ну и при чем сдесь архитектура системы?


Многопользовательские системы с толстым клиентом - это однозначно грязные данные.

"Однозначно грязные данные" - это когда у программиста руки растут из жопы. Думаю что в такой конфигурации наличие "грязных данных" можно обеспечить в любой системе. Я много лет просидел на, как Вы его называете, "толстом клиенте" (FMP 3,4,5,6), а "грязных данных" - так и не встретил.
31 авг 04, 13:45    [921347]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Люди, успокойтесь.

Отцепитесь от Злого. Ему оракл на голову упал. Теперь для него все остальное - типа не круто.

Можно сколько угодно спорить с человеком, который позволяет себе рассуждать о вещах, которые ни разу не видел и не пробовал. Его ни в чем нельзя переубедить. Он в 80-ом году книжку прочитал, до сих пор не может отойти.
31 авг 04, 14:07    [921481]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
ПОДходящее это когда исключена возможность грязных данных

заказчик - "лох позорный" и не поставил требований по чистоте данных


Слушайте, господин ЗлОй, Вы конкретно достали со своими "грязными данными"! Раскажите мне наконец как я могу получить "грязные данные" в ФМ? Я хоть посмотрю что это такое.


Я видел не одну систему разработанную с помощью RAD, и не две. Много я таких уродцев повидал, во всех видах видал. Как правило задача ставилась в таком ключе: "выяснить как "оно" работает, задокументировать, написать нормальную спецификацию, и реализовать по-нормальному". Клиенту это стоило от 120 долларов в час.

Ну и я видел достаточно уродливых систем, разработанных как по методологии RAD, так и по другим методологиям. И мы переделывали такие системы за 120-150 $/hr. И что это доказывает? Что методология RAD плоха? Ну возможно. А ФМ сдесь причем?


Для одного юзера Файлмэйкер и Аксесс вполне канают. Как только юзеров более одного - все выбросить и переписать.

FileMaker Server 7 gives you easy-to-use, yet powerful features that allow you to: Share databases with 2 to 250 users.
31 авг 04, 14:15    [921521]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Алексадр Зуев
Повторяю.

Чтобы в базе работало больше одного пользователя - надо оракл
Чтобы не приходилось работать напрямую со структурой данных на жестком диске - надо двух-, а лучше трех-, а еще лучше восьмизвенку. Каждое звено - на оракле конечно.
Чтобы не допустить появления грязных данных - надо перестать использовать RAD, и клиентские части программировать на ассемблере
Чтобы сделать ссылочную целостность - надо оракл
Чтобы установить блокировку на страницу - надо оракл
Чтобы установить блокировку на запись - надо оракл
Чтобы не ставить блокировок - надо версионник, читай "оракл"
Чтобы хорошо спроектировать базу данных - надо оракл, потому что плохо спроектировать базу данных на оракле нельзя
Чтобы написать хорошую клиентскую часть - надо писать на ассемблере, это раз, ну и конечно же под оракл, это два. Потому что под оракл на ассемблере невозможно написать уродскую клиентскую часть.
Чтобы заказчик не был лохом позорным - надо оракл, потому что Лох Позорный близко к ораклу не подойдет.
31 авг 04, 14:25    [921579]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
Ну все, теперь будем ругаться?
Картинка с другого сайта.Картинка с другого сайта.
31 авг 04, 14:37    [921645]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Да
31 авг 04, 14:42    [921679]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
SergSuper
Александр Зуев, бросайте этот ФМ.

Почему?! У меня прекрасная работа, отличная зарплата, и счастливые заказчики, а Вы предлагаете мне всё это бросить наслушавшись бредней выжившего из ума оракловца?


И самое плохое что Вы думаете что это правильно. Потом Вы это поймёте.

Давайте расставим точки над i. Я работаю на ФМ много лет. Разработал десятки сложнейших систем, не провалив при этом ни одного проекта. Знаю о ФМ всё, вплоть до закрытых для простых смертных механизмов индексации. Вы познакомились с ФМ только вчера, и тем не мение у Вас хватает смелости утверждать что есть "неправильно"?


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

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


Кстати у меня эта базы занимает меньше 100М, поиск естественно делается мгновенно(т.е. сравнимо с временем нажатия на клавишу). Ну и дополнительные возможности всякие еще сделаны, типа адрес надо писать "Мурманская область, г. Мурманск", а юзер пишет только Мурманск и ему выдаются варианты регионов где этот город(или посёлок, улица) может быть.

Ну круто!
31 авг 04, 14:45    [921698]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
представление о продукте получил, буду избегать
Вам бы следовало прежде всегор избегать самого себя. Ваше ехидство в скором будущем обернется против Вас же самих - поверьте!
А то что по слову "Мурманск" выводится список верных адресов - чему удивляться. А у меня компьютер начинает кричать (в самом прямом смысле), что клиент деньги просрочил когда он их не приносит вовремя, с одновременным показом его фото. Это что очень круто да? Все можно сделать! Главное - надо делать это быстро и вовремя. А не делать вид, что поставленная задача - очень тяжелая и срывать с клиента огромные деньги. А еще после этого клонить в сторону обслуживания программы. Я в своих постах писал о бухгалтерской программе. Так вот - ее писало 40 человек, втечение 3-4 лет. Единственную "пользу", которую она приносит предприятиям - это то, что она позволяет вместо четырех бухгалтеров на предприятии держать 10. Плюс еще и то, что бухгалтеру приходится проходить специальные курсы для работы с этой программой. Было бы вернее , если на предприятии есть программист, который может быстро исполнить все запросы того или иного бухгалтера. Нельзя написать программу удовлетворяющую запросам всех предприятий - 1С это одна из таких попыток.
Потому и по всей Росси "требуется "программист" знающий Microsoft PLUSS и 1С". На лицо - результат неверного использования SQL .
31 авг 04, 16:12    [922170]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Начнем с Оракла. Хоть я и предпочитаю эту СУБД всем остальным, что в общем-то видно невооруженным взглядом, я по долгу службы работаю еще и с Teradata, DB2, MS SQL, раньше работал с Информиксом пока наша контора от него не отказалась. Набор различных фич у Оракла самый богатый, что признают даже его оппоненты. Не все умеют ими пользоваться, но это уже другой вопрос. А вообще для многих задач можно и без Оракла обойтись, тем же DB2, Teradata, MS SQL, Sybase. Некоторые небольшие задачи решаются даже оупенсорсными базами. Так что Оракл я конечно люблю, но к другим СУБД отношусь вполне терпимо, если они этого заслуживают. И даже работаю с ними. Teradata так мне просто нравится, для Data Warehouse c терабайтами данных. Шустро так full table scan делает - ораклу и не снилось. Так что не надо мне приклеивать ярлык "выжившего из ума ораклоида".

А теперь про СУБД на модели файлового сервера. В "чистом виде" СУБД на модели файлового сервера оперируют именно Файлами. На клиенте имеется некая программа, выдающая себя за базу данных, которая общается с сервером на уровне ФАЙЛОВОЙ системы. То есть в качестве протокола выступает например SMB, NFS и им подобные. Распределенные файловые системы создавались с целью по возможности эмулировать семантику локальной файловой системы. На 100% это сделать естественно не удалось. В случае если несколько клиентов одновременно открывают файл на сервере, то это он ведет себя примерно так же как если несколько программ открывают один файл на локальной файловой системе. Если же одна их программ - читатель, а другая - писатель, то ни о какой целостности данных говорить не приходится. Соответственно этим программам надо как-то друг с другом договариваться. Имеем вывод:
- Распределенные файловые системы сами по себе не обеспечивают надежного конкурентного доступа к данным
- Для построения многопользовательской СУБД, кроме совместного доступа к данным требуются еще и механизмы синхронизации этого доступа
То есть распределенные файловые системы не предназначены для построения на их основе баз данных.

Каким же образом мы можем синхронизировать доступ к данным? Простейший способ - блокировать файлы при записи в них. К чему это приведет понятно - производительность будет гавнецо. Да и файлы придется таскать по сети почем зря. Пробовали еще создавать на сервере файлы блокировок, ни к чему хорошему это тоже не привело. В этом строители файловых серверов убедились на практике еще в конце 80х годов прошлого века. Тогда был сделан вывод, что требуется некая программа (назовем ее условно мэнеджером блокировок) которая будет жить на сервере, и управлять доступом к файлам. Поскольку протоколы распределенных файовых систем не позволяют нам эффективно управлять доступом к данным, мы сбоку лепим свою приблуду которая это делает. Дальше - больше. Раз уж мы решили что на файловом сервере будет жить наш "агент" так почему бы его не нагрузать дополнительными полномочиями типа обеспечения уникальности первичных ключей? Ну, раз пошла такая пьянка, тогда пусть он, падла, еще и SQL понимает. И что мы имеем в итоге? Жалкое подобие нормальной (Oracle, DB2, Sybase, ...выбирай на вкус) СУБД. То есть от модели файлового сервера с которой все начиналось мы постепенно уползаем все дальше и дальше, и все время как-то подозрительно приближаемся к мождели клиент-сервер.

Таким образом имеем постепенное перерождение от файловых серверов в "чистом виде", через некий гибрид файлового сервера с клиент-сервером, и наконец в сторону клиент-сервера. Открою страшную тайну: Оракл через это тоже прошел в свое время, но это было в начале 80х. Соответственно все то что (Oracle, DB2, Sybase, ...) изобретали и совершенствовали за прошедшие 20 лет, умельцы из Filemaker пытаются сделать заново. Сейчас они где-то на уровне 5го Оракла и находятся. Ну что ж, "флаг им в руки, и барабан на шею". Только своим клиентам я такую рвань ставить не буду - зачем?

Надеюсь что с файловыми серверами мы наконец разобрались? Теперь разберемся с проектированием, раз и навсегда. Нормально спроектированная система не позволяет иметь грязные данные. Нормализация, органичения целостности - все для этого. Нерюхи которые это не используют, в том числе маститые Sap, BAAN имеют грязные данные. Чтобы система нормально работала, она должна быть нормально продумана. Всякие методики типа экстремального программирования по сути хакерский подход. Я всегда был сторонником что надо сначала подумать - порисовать, а если задача сложноая то еще и прототипчик забацать и обкатать, а только потом уже садиться делать систему. Долго - да, и недешево впридачу. Зато переделывать не придется. Если кто-то любит быстро наваять, а потом всю жизнь переделывать - "вперед и с песней", но без меня.

Я очень рад за уважаемого Александра Зуева, которому удалось решить проблему над которой до сих пор бьются SAP и BAAN. А именно как обеспечить в многопользовательском приложении чистоту данных не используя constraints. Советую продать это ноу-хау за жуткие бабки.

А вообще-то файлмэйкер можно использовать, для написания клиентов. Типа того же PowerBuilder'а, цеплять его к нормальной СУБД через ODBC и вперед. Естественно при этом разрабатывать базу надо "как положено" от концептуального дизайна через лгический к физическому, а не начинать с отрисовки форм. Но таких инструментов для написания клиентских приложений миллион, всякие Delphi, Powerbuilder, список можно продолжать долго. Более того, клиент нынче пошел ушлый, хочет веб-приложения которые живет на сервере, чтобы не иметь головняк с их переустановкой по десктопам. Но это уже совсем другая история.
31 авг 04, 20:02    [923158]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
Я очень рад за уважаемого Александра Зуева, которому удалось решить проблему над которой до сих пор бьются SAP и BAAN. А именно как обеспечить в многопользовательском приложении чистоту данных не используя constraints. Советую продать это ноу-хау за жуткие бабки.

Александр Зуев
Зл0й
Отказ от constraints, даже в пользу триггеров часто приводит к грязным данным.

Возможно, но какое это имеет отношение к ФМ? В ФМ можно реализовать любые "constraints"!
31 авг 04, 20:48    [923274]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Пипец какой-то.
У Злого налицо явные проблемы с логикой.

Имеем вывод:
- Распределенные файловые системы сами по себе не обеспечивают надежного конкурентного доступа к данным

Правильная мысль
- Для построения многопользовательской СУБД, кроме совместного доступа к данным требуются еще и механизмы синхронизации этого доступа

Правильная мысль
То есть распределенные файловые системы не предназначены для построения на их основе баз данных.

Из двух правильных мыслей - умудрились слепить одну неправильную. Финиш.

Я чуть-чуть от баз данных отойду, ладно? А то безумного ораклоида не переспорить :)
- Разделяемая между различными процессами память сама по себе не обеспечивает надежного конкурентного доступа к данным
- Для обеспечения синхронизации работы нескольких параллельных процессов с разделяемыми данными, кроме совместного доступа к данных требуются еще и механизмы синхронизации этого доступа (протокол совместной работы)
- То есть разделяемая память не предназначена для совместного использования параллельными процессами.
Брррр... Перечитал... Ужаснулся...
Злой, ты не ужасаешься когда свои сообщения перечитываешь?

Каким же образом мы можем синхронизировать доступ к данным? Простейший способ - блокировать файлы при записи в них. К чему это приведет понятно - производительность будет гавнецо.

Понятное дело. Говнецо.
Да и файлы придется таскать по сети почем зря.

Понятно. Бред сивой кобылы. Для блокировки файла не нужно его никуда тащить. Поздравляю вас, товарисч Злой, вы обосрались в очередной раз.

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

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

Дальнейшее комментировать невозможно, ибо оно построено на изначально неверных посылках.

З.Ы. Я очень рад за терадату с хранилищами на терабайты данных. Но вы просто не в ту тему залезли. И никак это не поймете.
Танк - очень хорошая, мощная и надежная машина. Никого не боится. Хер завалишь. Всех убьет.
Но на трассе на мотоцикле я вас сделаю как стоячего (при том, что ни разу до этого не ездил на нем). Надеюсь вы не настолько глупы чтобы с этим спорить?
Вот и не рассказывайте о преимуществах танка в топике, где обсуждается конкретная модель мотоцикла. Тем более со смешными аргументами типа "мотоцикл плохо потому что педали надо крутить (по телевизору видел)"
31 авг 04, 22:02    [923348]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Я пробежался по всем Вашим постам, господин ЗлОй, выжал всю "воду" и оставил только те замечания, которые, в той или иной мере можно назвать аргументами против ФМ. Многие из них повторяются, на многие я уже отвечал, но всеже отвечу кратко на каждый ещё раз:

Зл0й
Чем отличается нормальная СУБД от всякой рвани типа файлмэйкеров, клипперов, и прочей файлсерверной ерунды? Тем, что позволяет делать блокировку на уровне записи

ФМ - позволяет.


Не масштабируются такие системы

У меня всё прекрасно масштабируется, легко и по всем направлениям (таблицы/пользователи/группы) - даже без снятия базы с сервера.


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

В штатах и в России работают десятки моих систем - все без исключения многопользовательские.


кроме блокировок на уровне записи полноценная СУБД умеет еще "вагон и маленькую тележку" того, что не умеют Клиппер с ФайлМэйкером, и никогда уметь не будут. От ACID транзакций до Hot Backup.

На основе понятия ACID транзакции, тоесть на основе того понятия, что операция по изменению записи БД есть атомарное, согласованное, изолированное и долговечное действие, работал и ФМ 3, а в ФМ 7 появилась ещё и возможность выполнять Hot Backup.


Имеется 2 таблицы "работник" и "отдел". И отношение "один ко многим" между ними. Требуется реализовать ограничение целостности. В нормальной СУБД это делается в 1 или 2 строчки.

В ФМ это вообще происходит автоматически.

- Код приложения не должен напрямую оперировать физическими структурами данных на диске

ФМ-клиент - не может, потому и не оперирует.


- Между приложением и СУБД должен быть API

В связке ФМ-сервер <-> ФМ-клиент этот API называется сетевым протоколом (собственный протокол ФМ - не SMB, NFS и пр.)


независимость клиентского приложения от сервера позволяет выполнять их на разных копмьютерах, общающихся по сети.

ФМ позволяет не только на разных компьютерах, но и на разных платформах.


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

В ФМ у меня всё прекрасно работает уже много лет.


за то время пока производители аксессов и файлмэйкеров вылизывали свой интерфейс, производители серверов занимались вот чем:
- блокировки на уровне записи, борьба с deadlock, масштабируемость
- поддержка хранимых процедур, триггеров, развитие языков на которых они пишутся
- поддержка ACID транзакций
- поддержка hot backup, больших баз, ...

В ФМ блокировка и пр. было всегда, хранимых процедур у нас нет, и слава Богу, ACID было всегда, hot backup появился в ФМ 7, там же увеличили размер базы до 8 терабайт.


до нормального клиент-сервера (хотя бы Оракл 6 образца 1988 года) Filemaker server еще как до луны.

- Ничем не аргументированное утверждение.

Filemaker и ему подобные продукты, вкупе с родстенной им идеологией разработки приводят вот к чему:
- вся логика на клиенте
- надежных механизмов обеспечения целостности данных нет

В ФМ 7 вся логики перенесена на сервер, а необходимые механизмы обеспечения целостности данных были в ФМ всегда.


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

В ФМ имеет достаточный набор инструментов для обеспечения контроля за вводимыми данными.


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

В ФМ не составляет никакого труда строить структуры на основе реляционных ключей (первичный/вторичный), с учетом блокировок и конкурентного доступа. Я, честно говоря, вообще не представляю себе как иначе можно построить RDB.


Многопользовательские системы с толстым клиентом - это однозначно грязные данные.

За много лет работы с ФМ данные моих клиентов ни разу не запачкались.


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

В ФМ превосходно реализована поддержка ограничения целостности.


Для одного юзера Файлмэйкер и Аксесс вполне канают. Как только юзеров более одного - все выбросить и переписать.

Однопользовательские системы на ФМ я никогда не писал - минимум 10 пользователей, максимум - 150. Все написанные мной системы продолжают работать устойчиво и в настоящий момент.


все то что (Oracle, DB2, Sybase, ...) изобретали и совершенствовали за прошедшие 20 лет, умельцы из Filemaker пытаются сделать заново. Сейчас они где-то на уровне 5го Оракла и находятся.

Предъявите уже наконец источники Вашей информации!

Это - всё. Остальное - рассуждения о эволюции баз данных, правилах проектирования систем, и прочий треп не имеющий никакого отношения к обсуждению ФМ. Вывод напрашивается печальный - Вы, господин ЗлОй, обыкновенный болтун. Впрочем, если Вы можете доказать хоть один из своих аргументов - милости прошу!
31 авг 04, 22:12    [923355]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Действительно ФМ позволяет делать блокировку на уровне записи, но так что уж лучше бы не позволял. Про deadlock detection слышали?

У вас все прекрасно масштабируется. Рад за вас. Я масштабирующихся систем на файлмэйкере пока не видел. Как и систем на файлмэйкере где бы использовались ограничения целостности. Последние - вообще отдельная тема. Вы знаете как они в ФМ реализованы? Если есть parent-child relationship, что происходит за кулисой когда мы пытаемся данные менять? Может там случаем блокировка какая происходит, и как оно отражается на производительности многопльзовательской системы? Никогда не задумывались на этот счет? Или хотя бы мерили производительность системы под нагрузкой?

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

Теперь про ACID транзакции. Порядочные СУБД их поддерживают не только на уровне записи, но и на уровне SQL запроса или на уровне нескольких запросов. Поясню: я объявляю серверу что я начал транзакцию и хочу иметь например согласованное чтение во всех последующих SQL операторах вплоть до самого commit/rollback. Файлмэйкер такое могет или как?

"Механизм контроля за вводимыми данными" находится на клиенте или на сервере? Так у нас система с "толстым клиентом" или как? SAP тоже вроде-как имеет свои механизмы контроля. Только как только мы пытаемся вынуть из нее данные и загрузить их в какую-нибудь аналитическую базу, сразу выясняется что они не работают по нормальному. Думаю что ваши клиенты просто ни разу не делали никакой аналитики по данным. Если к данным особо не приглядываться то и сомнения в их чистоте не возникают. Скажите, данные разработанных вами на ФМ баз кто-нибудь когда-нибудь вынимал? Строил по ним time series? Анализировал?

Что до строительства реляционных БД без вторичных ключей - это к производителям ERP пакетов. Я, к сожалению, представляю как это делается. Поубивал бы!

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

С шаренной памятью все просто - сама по себе, без семафоров (условных переменных, spin locks, latches и иных механизмов межпроцессной синхронизации) она не шибко помогает строить сервера. Представьте себе что два процесса одновременно модифицируют двусвязный список. Что будет?
1 сен 04, 03:47    [923500]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Gluk (Kazan)
Member

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

По моему, Вы напрасно тратите свое время, Вас здесь не поймут :(
О чем вообще говорить, если механизм индексации преподносится как
жуткая корпоративная тайна за семью печатями. 90-е года прошлого века.
1 сен 04, 08:16    [923596]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Механизм индесации как ужасно секретное ноу-хау это конечно клево. Видимо когда я его в 80х годах прошлого века реализовывал на СМ-4, СМ-1420 я был сильно крут ;) Правда я тогда считал себя начинающим программистом.
1 сен 04, 09:30    [923773]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Злой
Вы хотя бы читаете то, что вам пишут?
Злой
Имелось ввиду что сами по себе файловые системы не подходят для организации многопользовательских БД

Ну да. Сами по себе - не подходят. Я уже сказал, что это есть правильная мысль.
Сами по себе автомобильные дороги не обеспечивают безопасность передвижения по ним автотранспорта.
Поэтому помимо совместно используемого ресурса (дороги) необходим протокол совместного использования (ака ПДД)
Из этих двух посылок - вы опять делает вывод, что автомобильные дороги не подходят для использования их сразу несколькими автомобилями. Я так понимаю, что и сами по себе они не подходят, и не сами по себе они все равно не подходят.
Или я чего то не понимаю???

Злой
MS SQL почему-то не использует файлы блокировок, в отличие от Аксесса, и масштабируется MS SQL получше

Да мне как-то все равно, что там в MS SQL не используется.
Вам привести пример серверов (НЕ файл-серверов), которые тоже не используют файлы блокировок, и при этом маштабируются похуже MS SQL?

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

Злой
файлы блокировок - муханизьм допотопный, галимый и "взрослые" СУБД так не делают

Благодарю. Теперь я знаю, что такое нормальные (а не высосанные из пальца) аргументы.
Продолжать с вами диалог - бессмысленно.
1 сен 04, 09:38    [923800]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Во, я наблюдаю товарисча Gluk'а, который (по крайней мере раньше) производил впечатление вменяемого ораклоида.

Быть может товарисч Gluk сумеет объяснить мне смысл этой последовательности утверждений:
выживший из ума ораклоид
Каким же образом мы можем синхронизировать доступ к данным? Простейший способ - блокировать файлы при записи в них. К чему это приведет понятно - производительность будет гавнецо

выживший из ума ораклоид
Пробовали еще создавать на сервере файлы блокировок

выживший из ума ораклоид
Давайте пораскинем мозгами и прикинем к чему это приведет. Где у нас будет "узкое место" в плане производительности

Чета я не понимаю - а чего они мучались-то? Блокировать хранилище данных - непроизводительно, завести для блокировок отдельный файл - видимо ни на йоту не производительнее (по мнению Злого). Чего хотели, зачем пытались...

На товарисча Gluk'а последняя надежда. Ибо мысли человека, которому на голову даже не оракл упал, а целая терадата - мне не понять без посторонней помощи.
1 сен 04, 10:07    [923904]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Whois2
Guest
Лох, домен твоей страны случайно не .am?
1 сен 04, 10:13    [923946]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить