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

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

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

А теперь об архитектурных решениях, модели клиент-сервер, и масштабируемости. Системы обработки и хранения информации можно условно поделить на монолитные и модульные. Деление это условно, ибо в любой мало-мальски грамотно спроектированной "монолитной" системе есть зачатки модульности. Достоинста модульности общеизвестны, одно из основных - возможность эффективной распределенной обработки. Это и называется архитектурой клиент-сервер. Есть хорошо оговоренный API между подсистемой занимающейся хранением данных (и в ряде случаев реализацией бизнес-логики) и подсистемой занимающейся рисованием форм и отчетов. Это в основном SQL, остальные языки запросов (например QUEL) на сегодняшний день практически вымерли. Монолитные системы не имеют перспектив и на сегодня четко занимают нишу "legacy systems". Разрабатывать монолитную систему бесперспективно. Заменять одну монолитную систему (Access) другой (filemaker) это по сути обмен шила на мыло. Все равно что взять систему написанную на Foxpro для DOS и переписать её на Clipper. Пустая трата денег, ибо лучше она от этого не станет.

Современные монолитные системы (Access,...) представляют собой средство разработки и реализации базы и приложения "в одном флаконе". Как и любая система делающая "все" она делает все плохо. Более того, такие системы ужасно дорого поддерживать. То есть навалять что-то по-быстрому можно, но "вход рубль - выход два". Архитектурно все эти системы относятся к категории "толстого клиента". Создатели "толстых клиентов" пытаются заново "ручками" сделать все то на что Oracle, Sybase и IBM потратили десятки лет и много миллионов долларов. Более того, "to add insult to injury" эти системы еще и гоняют большие объемы данных по сети почем зря, плюс страдают от проблем типа взаимной блокировки, решенных еще 15 лет тому назад, во времена Oracle 6. Некоторые создатели "монолитов" (СУБД основанных на модели файлового сервера), осознав бесперспективность данной архитектуры, пытаются от нее уползти. Даже предлагают рудиментарные поделки представляющие собой жалкое подобие полноценных СУБД. Поздно, братцы, опаздали лет этак на 15. Поезд ушел

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

Вот поэтому даже самый зачуханный SQL сервер типа весьма нелюбимого мною MySQL, на порядок "грамотнее" Аксессов, Файлмэйкеров, Клипперов и им подобных допотопных кадавров. Если поджимает бюджет - поставьте себе что-нибудь халявное из MySQL, PostGreSQL, Firebird, MaxDB/SapDB, Ingres. Или старую версию Sybase, которая халявная. Или что-то недорогое типа MSSQL, или Oracle Standard Edition. Главное - не связывайтесь с технологиями типа Аксесса и Файлмэйкера.

А любого паразита который попытается вам "впарить" такую гадость гоните взашей. Особенно если он основ проектирования не знает.
30 авг 04, 06:58    [916765]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
Вам бы следовало перечитать все то, что написано выше. Вы видно уже забыли о чем там писалось, или не читали вообще. Вы видно из тех людей, которые при диалоге видят только себя и слушают только себя, красуясь перед самим собой. Вы непробиваемый. Вам трудно что либо вдолбить. Да и нет смысла, я вижу. Вы уперлись в одно, и больше ничего не хотите понимать. Перечитайте!
30 авг 04, 10:29    [917075]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Злой
Простите, но ваши рассуждения о файл-серверах и "монолитах" выглядят весьма смешно. Если не разбираетесь в предмете - то и не позорьтесь на людях.
Ссылочную целостность блин не смог сделать. Клоунада блин какая-то.
30 авг 04, 10:46    [917167]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Bzjums
Member

Откуда:
Сообщений: 7
Ох, господин, Злой, ну и злой же Вы!

Собственно, как уже многие тут высказывались, Вы беретесь судить о том, чего не знаете, Вам только кажется, что вы знаете. Прогресс ушел далеко вперед, а Вы все старыми категориями мыслите.
Ваши рассуждения об этапах проектирования – это каноны АСУ семидесятых годов прошлого столетия. В те времена можно было себе позволить разработку систем АСУ в течение нескольких лет.
Кто же сейчас будет столько ждать? Да за период проектирования такой системы она морально устареет и в смысле софта, да и сама постановка задачи устареет. Пользователь стал другой, в большинстве случаев достаточно грамотный, чтобы, как говорит Александр Зуев, рассматривать проект базы на уровне отрисованных окон в FM.
И почему Вы решили, что FM – это «монолитная» система? Если при проектировании на FM нет необходимости писать серверную часть, нормального прогрессивного специалиста это должно бы заинтересовать, а Вы сразу: « Такого не может быть, потому что не может быть никогда»! А может все-таки почитаете что-нибудь о файлмекере, познакомитесь с конкретными разработками в FM, прежде чем хаить его?
Ваши рассуждения настолько примитивны, они достойны только Злого консерватора.
В свое время, то есть в те далекие семидесятые годы прошлого столетия, проектировщики АСУ, которые писали свои экономические задачи еще на КОБОЛЕ, мечтали о такой базе, как файлмекер.
Господин Злой, мой Вам совет, умерьте свою злобу, не отзывайтесь неуважительно о специалистах, работающих на FM, познакомьтесь с файлмекером подробнее. А потом уже делайте выводы.
30 авг 04, 15:11    [918478]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
автор
Прогресс ушел далеко вперед, а Вы все старыми категориями мыслите.

и что же изменилось в проектировании?
а ну-ка ознакомьте нас с новыми современными принципами проектирования
30 авг 04, 15:29    [918584]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Bzjums
Member

Откуда:
Сообщений: 7
Этапы проетирования АСУ какие были, такие и остались, да только на практике, многие опускаются, т.к. пользователь стал гораздо более грамотными. Да ведь не это важно в данном случае,
форум не о том. Мы, кажется, обсуждаем возможности файлмекера, как современной СУБД, позволяющей оперативно и надежно реализовывать решения по АСУ, легко вносить изменения, дописывать и дорабатывать дествующую базу без остановки уже функционирующей базы.
30 авг 04, 16:14    [918849]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
Bzjums
Да ведь не это важно в данном случае

как же "не важно"? А коллега Ваш утверждает, что

Александр Зуев
Опытные разработчики начинают проектирование БД ФМ с отрисовки основных экранов "клиентской части".

какая-то нестыковка получается - Вы говорите, что всё осталось как было, то бишь интерфейс рисуется в последнюю очередь, а опытные разработчики утверждают обратное? И кому верить в таком случае?
30 авг 04, 16:43    [918998]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
кстати, интересно, а с чего начинают проектирование бд фм неопытные разработчики?
30 авг 04, 16:45    [919017]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
Dedushka Mazai
И кому верить в таком случае?

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

З.Ы. Я из файл-серверов тока аксес знаю. Может действительно в файл-мейкере нет ни блокировок, ни ссылочности? Тады прошу прощения у Злого.
30 авг 04, 16:47    [919025]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Bzjums
Member

Откуда:
Сообщений: 7
А вот нестыковочка-то главная состоит в том, чтобы судить о чем-то надо ЭТО знать. А чтобы понять как использовать FM, почитайте руководство, да поробуйте спроектировать что-нибудь свое, а потом будем делать выводы.
Я думаю, многие вопросы отпадут сами собой.
30 авг 04, 16:54    [919068]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

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

ЗЫ: кстати, где можно скачать какой-нибудь рабочий проект, написанный на фм? просто интересно посмотреть
30 авг 04, 17:11    [919181]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
SergSuper
Александр, если б все такие задачи были простые как КЛАДР...
Ну возьмём для примера её. Допустим мне надо по вводимому адресу строчкой проверить корректный ли он. Интерфейс простой: есть строка редактирования, когда курсор с неё уходит при некорректном адресе появляется предупреждение об этом.
Итак вы создали этот интерфейс и получили прибамбаху? Есть у меня смутные сомнения...
Когда я у себя реализовывал базу адресов, я думал до какой степени надо нормализовывать, должна ли оставаться связи с данными из НИ, какие другие приложения смогут её использовать, чем мне жертвовать - производительностью или местом на диске и т.д. Заметьте что все эти вопросы не касаются именно SQL - это общие вопросы хранения данных. Вы хотите сказать что все их за меня решит ФМ? Опять же смутные сомнения...
Я пытаюсь понять как же это решается на ФМ, но в ответ моряк с лётчиком. Мол всё круто, но вам не понять. Я не прошу меня учить, мне просто интересно какие есть еще концепции работы с данными.

Насчет "моряков с летчиками" - сори, это я не Вам, это я ЗлОму. Вероятно мне следовало это уточнить, тогда может быть он и не стал бы мучить нас своим "Монолитным" пасквилем... :-)

Сама задачка с КЛАДР-ом, на самом деле оказалась не такая уж и простая. Пару дней мне над ней попотеть пришлось. Условием задачи было не проверка, а поэтапный выбор адреса. Все таблицы КЛАДР я слил в одну общую таблицу, состоящую из 13 хранимых и 3 калькулируемых полей. В таблице оказалось 740650 записей. Размер файла (таблицы) составил 767 МБ. Одно из калькулируемых полей таблицы выполняет функцию реляционного ключа. В нем, через перевод строки даны полный код адресного объекта, код адресного объекта верхнего уровня, сокращение типа объекта (г, р-н, ул) и первые 3 буквы наименования. Формула расчета реляционного ключа выглядит так:

Substitute(Substitute(Substitute(Substitute(Substitute(

CODE & 
"¶c" & 
"¶c n1" & 
"¶c n2" & 
"¶c n3" & 
"¶c s" & 
"¶c s n1" & 
"¶c s n2" & 
"¶c s n3",

"c", Case(

(Length(CODE) = 11 or Length(CODE) = 13) and TextToNum(Middle(CODE, 12, 2)) = 0, 

Case(
TextToNum(Middle(CODE, 3, 9)) = 0, "0", 
TextToNum(Middle(CODE, 6, 6)) = 0, Left(CODE, 2), 
TextToNum(Middle(CODE, 9, 3)) = 0, Left(CODE, 5), 
Left(CODE, 8)), 

Length(CODE) = 17 and TextToNum(Middle(CODE, 16, 2)) = 0, Left(CODE, 11), 

Length(CODE) = 19, Left(CODE, 15), 

"X")), 

"s", SOCR), 
"n1", Left(NAME, 1)), 
"n2", Left(NAME, 2)), 
"n3", Left(NAME, 3))

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

01003000020000700
01003000020
01003000020 С
01003000020 Со
01003000020 Сов
01003000020 ул
01003000020 ул С
01003000020 ул Со
01003000020 ул Сов

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

Порталы во всплывающем окне фильтруются по типу и/или первым буквам наименования. К примеру, находясь а уровне выбора улицы оператор видит весь список улиц города. Если он вводит первые буквы наименования, то список сокращается. Работу этого механизма обеспечивает реляционный ключ приведенный выше. В этом ключе значения приведенный в столбец отвечают условию ИЛИ, а значения приведенные в строку - И. Отработка фильтра происходит мгновенно.

После завершения выбора полученный адрес копируется целиком в текстовое поле другой таблицы (той, для которой адрес собственно и выбирался). Кроме адреса туда копируется его полный код. Если оператор хочет изменить адрес, то по коду восстанавливается вся цепочка выбора. Связи между КЛАДР и теми таблицами, в которые вставляются адреса я делать не стал.

Интерфейс выбора адреса реализован в отдельной таблице. Записей в ней нет, только глобальные поля, скрипты и реляции обеспечивающие процесс выбора адреса. Всего в этой таблице 46 полей, 19 реляционных связей и 28 скриптов. Описать это всё довольно сложно. Если интересно - сдесь я выложил этот салюшен. Для запуска придется устанавливать ФМ.

Ссылку которую Вы привели - ну извините, ну это же полный примитив, примерно такое есть в любом средстве работы с БД.

Вы хотели понять как в процессе разработки на ФМ клиентской части получается серверная, - я проиллюстрировал.

На самом деле, в ФМ конечно можно разделить клиентскую и серверную части. Просто это крайне редко бывает целесообразно делать. Разрабатывать на ФМ фронт-энд системы может быть эффективно только для сетей с низкой пропускной способностью, типа Dial-up.

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

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

If [Transaction:Amount > Account::Total]
   Set Field [Transaction:IvalidFlag, 1]
Else
   Set Field [Account::Total, Account::Total - Transaction:Amount]
End If

Это - если Вам нужно в целях ускорения расчетов хранить текущее значение поля Account::Total. А если записей в таблице Transaction не очень много, то поле Acount::Total проще сделать калькулируемым, а в скрипте только менять флажек транзакции.

Или например как выбрать счета по которым не было движений за определённый период.

Поиском:

Enter Find Mode []
Set Field [Account::LastDate, "<" & <начало_периода>]
New Record/Request
Set Field [Account::LastDate, ">" & <конец_периода>]
Perform Find []

Я охотно верю что там процедур и триггеров нет, но что есть?

Скрипты.

Ну и напоследок не могу не придраться к фразе: выбор из БД на 500 тыс. записей занимал секунд 20.

Насчет 20 секунд - это я пытался выразить как быстро оператор находит нужный адрес. Сейчас попробовал сосчитать до 20, и где-то на 5 понял что глупость написал... :-)
30 авг 04, 17:11    [919185]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Dedushka Mazai
кстати, интересно, а с чего начинают проектирование бд фм неопытные разработчики?


Александр Зуев
Александр Зуев
Опытные разработчики начинают проектирование БД ФМ с отрисовки основных экранов "клиентской части".

Надо заметить что эта технология не подходит для "новичков". Если Вы только начинаете программировать в ФМ, то гораздо эффективней будет создавать реальные поля, кнопки и порталы, и тут же проверять как они работают.
30 авг 04, 17:18    [919209]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
да - недочитал. каюсь.

эк всё там с ног на голову перевернули
30 авг 04, 17:23    [919238]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Dedushka Mazai
дык мы проектирование обсуждаем

ага. а форум называется "Сравнение СУБД", а не "Проектирование БД"

хотя забавно конечно... про разработку начиная с кнопочек :)
30 авг 04, 17:45    [919351]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
автор
а форум называется "Сравнение СУБД", а не "Проектирование БД"

выходит, форум неправильно назвали. надо срочно переименовывать, чтобы вопросов больше не возникало
30 авг 04, 17:48    [919369]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Dedushka Mazai
принципы - они одни и те же, хоть под оракл, хоть под фм пиши.

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

ЗЫ: кстати, где можно скачать какой-нибудь рабочий проект, написанный на фм? просто интересно посмотреть

Сдесь.
30 авг 04, 17:48    [919373]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
Системы обработки и хранения информации можно условно поделить на монолитные и модульные.

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

Заменять одну монолитную систему (Access) другой (filemaker) это по сути обмен шила на мыло.

Более того, "to add insult to injury" эти системы еще и гоняют большие объемы данных по сети

FileMaker Server 7 perform searches and calculations on the server instead of the client.

Чукча - не читатель, чукча - писатель... Да? ;-)
30 авг 04, 19:24    [919660]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
- Анализ существующего бизнес-процесса и способов обработки информации

Это - само собой.

- Оптимизация бизнес-процесса

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

- Формализация и постановка задачи по автоматизации
- Концептуальное моделирвание
- Логическое моделирование
- Физическое моделирование

Эти четыре пункта я пожалуй выкину нафиг. Чего уж тут моделировать если уже и структура БД определена, к тому же у нас, на ФМ и возможностей-то выбирать механизмы хранения нет.

- Реализация модели
- Разработка приложений

У нас, на ФМ это - один пункт.

Итого, вместо восьми пунктов получаем три. Экономия времени - процентов 50-80. Требования заказчика полностью выполнены, ведь он же каждую кнопку утвердил. Внутренние механизмы работают устойчиво, ведь каждой кнопке уделяли внимание три раза (на этапе проектирования, утверждения и программирования).
30 авг 04, 20:27    [919746]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Лох Позорный
Может действительно в файл-мейкере нет ни блокировок, ни ссылочности? Тады прошу прощения у Злого.

Зря.
30 авг 04, 20:37    [919761]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Как все сразу разобиделись, ужас просто. Начали мне, нерюху, тыкать файл-мэйкер серврером. Ну да ладно. Знаем мы про файл-мэйкер сервер. Даже работали с ним. Это и есть тот самый "рудиментарный" сервер который поставщики аксессоподобных продуктов пытаются втюхать тем кто уже "подсел" на их продукт. Предлагаю рассмотреть развитие СУБД в объективно-историческом контексте, чтобы сразу стало понятно откуда у различных продуктов "ноги растут". Давным-давно, много лет тому назад, точнее в начале 70х годов прошлого века, кантуперы делились на миниЭВМ и Мэйнфреймы. Широкое распространение получили миниЭВМ фирмы Digital Equipment и мэйнфреймы фирмы IBM. Советским программистам они знакомы как СМ ЭВМ и ЕС ЭВМ соответственно. На раннем этапе развития СУБД на мэйнфреймах и миникомпьютерах были устроены примерно одинаково. Данные лежали в файлах, которые в мэйнфреймовой терминологии называются "наборы данных" (ISAM, VSAM, ... datasets). Реляционная модель изобретена еще не была, на рынке присутствовали иерархические и сетевые СУБД типа IMS. Подобные кадавры до сих пор присутствуют на рынке в нише legacy systems. Некоторые производители пытаются их "втюхать" под видом "постреляционных" продуктов, уповая на то что молодые программисты не знают что произошло в 70х -80х. А произошла вот какая штука: была изобретена реляционная модель. Типа избыточность данных должна быть изжита, и код приложения не должен оперировать физическими указателями на записи. Многочисленные поклонники сетевых и иерархических СУБД, в один голос утверждали что производительность реляционных СУБД будет слишком низкой. На самом деле реляционная модель не запрещает физические указатели как класс. Более того, индексы и индекс-организованные таблицы как раз и есть древовидные структуры основанные на физических указателях. Вся фишка в том, что наш код на SQL с этими указателями не работает, поэтому он независим от физической организации данных на диске. Имеем урок
- Код приложения не должен напрямую оперировать физическими структурами данных на диске
- Между приложением и СУБД должен быть API
Те кто усвоили этот урок еще в 80х годах прошлого века в конце концов и пришли к современным 2х-3х и более звенным системам клиент-сервер. К сожалению некоторая часть разработчиков продолжает упорствовать в своих заблуждениях и не признает реляционную модель. А ведь именно независимость клиентского приложения от сервера позволяет выполнять их на разных копмьютерах, общающихся по сети.

Вернемся к истории. В конце 70х появились персональные компьютеры (ПК), которые к 80м достигли мощности позволявшей далать на них простеньких клиентов и примитивные БД. В 90х мощность ПК настолько возросла что это привело к исчезновению миникомпьютеров как класса, и к стиранию грани между ПК и сервером. А что же произошло с СУБД в мире ПК? Они достаточно точно повторили эволюцию от файл-ориентированных систем (DBASE III+, FoxPro 2.x Clipper 5.x и им подобные) к системам клиент-сервер. Сначала БД работали на 1 ПК, безо всяких сетей, и все было "пучком". Как только к ним приклячили сеть и попытались делать на их основе многопользовательские системы, то моментальо "уперлись" в ограничения обусловленные монолитностью и нереляционностью данных систем. То есть оперирование физическими указателями на данные оказалось гнилой идеей как на мэйнфреймах так и на ПК. Старшее поколение еще помнит когда данные вынимались из таблиц с помощью вложенных циклов. В результате у этих систем выбор простой: или на свалку или долго и мучительно перерождаться в что-то реляционное и клиент-серверное. Этапы вырождения систем такие:
- БД на 1 компьютере без SQL
- неуклюжие попытки построения многопользовательских систем на модели файлового сервера (мы все знаем почему это не работает)
- уползание от модели файлового сервера в сторону "настоящих" клиент-серверных систем
То есть "урок" был в конце концов усвоен. Все бы хорошо, да "багаж" обратной совместимости тянет на дно. То есть доступ к данным с помощью SQL мы добавили, да старый код по прежнему его делает вложенными циклами. К тому же, за то время пока производители аксессов и файлмэйкеров вылизывали свой интерфейс, производители серверов занимались вот чем:
- блокировки на уровне записи, борьба с deadlock, масштабируемость
- поддержка хранимых процедур, триггеров, развитие языков на которых они пишутся
- поддержка ACID транзакций
- поддержка hot backup, больших баз, ...
Продолжать этот список можно долго. Filemaker server это продукт где-то сопоставимый с Ораклом 5й версии и уступающий последнему по ряду показателей. Плюс куча никому, кроме давно "подсевших" на Файлмэйкер, не нужного багажа.

Мораль такая: СУБД не построенные по модели клиент-сервер это дрянь. Факт в общем-то давно всем известный. А до нормального клиент-сервера (хотя бы Оракл 6 образца 1988 года) Filemaker server еще как до луны. При наличии вполне нормальных оупенсорсных СУБД, однозначно превосходящих Filemaker server по всем параметрам, я не могу понять людей использующих Filemaker. Средств для рисования окошек пруд пруди, причем независимых от БД. Не умеете писать SQL - есть куча всяких разных query builder'ов. Используйте нормальные СУБД а не технологии позавчерашнего дня.
30 авг 04, 21:07    [919793]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Михаил Едошин
Guest
Зл0й
Теперь мы, разрисовываем и расписываем как же происходит бизнес-процесс.


Ну все-таки бизнес-процесс; а я было уже плохо о вас подумал :)

Анализ существующего бизнес-процесса; несомненно, это и обсуждать не стоит.

Оптимизация бизнес-процесса? Это не обязательно. Бизнес-процесс может и не нуждаться в оптимизации или подчиняться внешнему процессу, менять который нельзя.

Формализация и постановка задачи? Концептуальное и прочее моделирование? Так ведь это и есть интерфейс. Конечно, не графический, но тем не менее это описание того, как решать задачи при помощи вашей системы — а это и есть описание интерфейса. Этим объясняется, например, потребность в формализации — это типичное и наиболее общее требование всех современных компьютерных решений. К бизнес-процессу формализация никакого отношения не имеет и сама по себе никакого выигрыша не приносит (за исключением побочного эффекта от того, что разработчик лишний раз подумает); нужна она именно потому, что мы намерены решать задачу при помощи, скажем старомодно, «счетно-решающего устройства».

(OFF. Если бы мы решали задачи при помощи волшебных эльфов (да что там эльфов — хотя бы при помощи приличного искусственного интеллекта), процесс разработки был бы совсем другим. Формализация и унификация, которые кажутся сейчас такими важными, а на самом деле всего лишь отражают ограничения современной вычислительной техники, отошли бы на второй план, а заниматься бы пришлось обучением ИИ (или мотивацией эльфов :) /OFF)

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

Отсюда сразу практические выводы. Во-первых, возможно, большие и сложные системы имеет смысл сначала описывать на абстрактном уровне, потому что детально описать их все равно не удастся. Но я не вижу, почему маленькие системы нельзя описывать целиком, особенно если бизнес-процессы не особенно сложны. Но это не так важно, как то, что составить правильное абстрактное описание, ни разу не «опустившись» до деталей, вряд ли возможно. Как мне узнать, что я на верном пути? Есть только один надежный способ — попробовать систему в работе и получить обратную связь. И как заказчик может поработать с предельно абстрактной моделью? Как мне получить вразумительную обратную связь от заказчика, если все, что я ему даю — это многостраничное скучное общее описание, где все вроде верно, с формализованными определениями, смысла которых заказчик все равно не понимает (и правильно делает — это детали реализации)?

А ведь при пробной обкатке, даже на бумажных моделях, может выясниться масса интересных деталей.

Например, может выясниться, что обычно пользователю нужны недавно использовавшиеся документы; значит, нужно их где-то хранить. В некоторых приложениях достаточно обойтись полем даты, а в некоторых неплохо бы иметь отдельную таблицу «периодов времени» (например, в бухгалтерии некоторых стран допускаются учетный «год» и «месяцы», существенно отличающиеся от календарных). Во многих простых системах бухучета основной единицей является «проводка»; однако более удобной основной единицей (а удобство выясняется только при практической работе) возможно, была бы «операция», объединяющая несколько проводок и параметризуемая суммой (шаблон). Все эти детали могут весьма существенно повлиять на «концептуальную» модель. И лучший метод для обнаружения таких деталей — это работа не над абстрактной моделью, где их нет(!), а над реальными формами и отчетами — как существующими, так и проектируемыми.

Теперь подробнее о процессе проектирования. Да, есть точка зрения, что это процесс поэтапный — сначала проект, потом реализация. Есть и серьезные против нее возражения — вряд ли можно «составить план жизни, всесторонне его обсудить, а затем уж жить по нему». (Тут закавычены (по памяти) слова Белинского, издевавшегося над подобной идеей; я с ним полностью согласен.) Например, в XP (да, мне нравится эта методология :) ), проектирование & рефакторинг продолжаются постоянно, а готовый продукт выдается на-гора итерациями, занимающими обычно от двух до четырех недель. Между прочим, «мэйнфреймовая бухгалтская система учета кредитов, написанная еще во времена Никсона» (это 1969-1974 гг., не так уж и давно), которая вам, как я понял, не очень нравится, скорее всего тоже создавалась в точности как вы описываете :)

Зл0й
Я тут пропущу этап где мы решаем сколько баз мы будем делать, например OLTP, ODS (Operational Data Store), DSS/Data Warehouse/Data Mart и прочие архитектурные решения, типа как мы их будем бэкапить, где у нас будет стэндбай, за сколько минут мы должны восстановиться если база упадет, какой объем транзакций должна выдерживать система, каково должно быть время исполнения транзакций итд. итп. Выбор железяки тоже расписывать не буду.


По-моему, вы пытаетесь хвастаться тем, какая у вас ответственная работа и какие сложные задачи вам приходится решать. It must be years of training and full employee benefits somewhere in corporate America, am I right? :) Но оттого, что есть сверхзвуковые «Конкорды» и специально обученные пилоты, «Сессна» и «АН-2» не перестают быть «настоящими» самолетами, а их пилоты — настоящими летчиками. Да и не везде на «Конкорде» и сунешься — поля от насекомых опылять или с парашютом прыгать лучше с «кукурузника». Или, по-вашему, поля опылять не нужно? Или нужно делать это на «Конкорде»? Убьетесь.

Зл0й
А теперь про бухгалтерию для малого бизнеса. Если нет какой-то злобной специфики, не позволяющей применить стандартные средства, то задачу надо решать СТАНДАРТНЫМИ СРЕДСТВАМИ. Я никогда не буду писать свой собственный awk, sed или perl. Зачем? Есть же готовое. С бухгалтерией — та же фигня. Только в редких случаях, где у клиента бухгалтерия шибко нестандартная, как например учет кредитов в банке, требуется софт заточенный конкретно под задачу. Если фирма продает сантехнику или оффисные товары то ей вполне проканает стандартная бухгалтерия. Нет там специфики, и задачи которая не решается стандартными средствами. А исконно российский вид спорта под названием «изобретение велосипеда» экономически неэффективен.


Ну так считайте FileMaker как раз таким стандартным средством, только более универсальным и требующим большей дополнительной настройки :) В нем решены некоторые задачи, над которыми вы ломаете голову, вроде «как мы будем бэкапить». Собственно, вариантов там нет :) Говорят же — RAD tool.

Кроме того, стандартных средств не так уж и много. Примеры из жизни: маленький спортивный магазин на горе в Швейцарии. Получают около четырех тысяч наименований товаров. Хотят (имеют полное право, на мой взгляд) автоматизировать склад. Не знаю, есть ли готовое решение, рынок такого ПО Швейцарии не проверял, но торговец этот пытается написать приложение на FileMaker. Зато я видел (стандартную) швейцарскую бухгалтерскую программу, позиционируемую вроде как для малого бизнеса, причем вроде как и популярную. На мой взгляд, не очень удобная. Настраиваемой автоматизации вовсе нет. Некоторые тонкие моменты, вроде уплаты VAT на импорт, сделаны через ж...; тоже видно, что сначала сделали проект, а эту деталь выяснили во время реализации и кроили уже по живому. IMHO, если это лучшее, что там есть, то даже для небольшой тамошней фирмы со стандартными задачами имеет смысл вложиться в разработку собственной бухгалтерии. Швейное производство: небольшие фабрики, шьющие мелкие партии одежды, работающие с множеством субподрядчиков, выполняющий отдельные операции, причем туда и обратно пересылается множество деталей и надо ни одну не забыть. Учет просто жизненно необходим. Я специально разыскивал в Сети, что есть из автоматического учета для таких контор; очень немного. Причем большая часть — откровенные страшилища. Из российской жизни: рекламная газета с версткой объявлений. Масса тонкостей, уникальных для каждой газеты; стандартного средства на рынке нет вовсе, я слышал только об in-house-разработках. (На FileMaker, кстати, можно будет гнать через XSLT хоть прямо в tagged text для программы верстки.) Рекламному издательству нужно рассчитывать стоимость заказов; проблема здесь в том, что стоимость, например, буклета складывается из множества слагаемых, т. е. «плоскими» счетами-списками не обойтись, нужно как-то собирать компоненты в структуру, да и к тому же не всю эту структуру раскрывать клиенту :) Естественно, там множество чисто вычислительных сложностей, вроде зависимости цены от тиража. Опять-таки, любопытно было бы глянуть на готовое стандартное средство; я о таком ничего не знаю.

FileMaker как раз очень удачно fits the bill в каждом из этих случаев. Он недорогой, простой и достаточно надежный; а возможности у него очень даже ничего. Проблемы, что вы описываете (на примере отделов и работников) на самом деле не так уж страшны. You ain't going to need it :) (XP) Даже если о них вообще не заботится, в реальной работе они сказываются очень редко. Например, когда я добавляю ссылку на товар к счету, мне теоретически вроде бы надо блокировать таблицу товаров, как вы говорите, «хотя бы для того, чтобы [товар] не удалили». На самом же деле в действительности товары будут удаляться крайне редко, а если и будут, так оттого, что были созданы по ошибке и, естественно, никто про них еще не знает и ни к какому счету в этот момент не добавляет. Если еще к тому же запретить удаление товаров, хоть раз попавших в счет (делается очень легко), то практически проблема целостности данных будет решена. Не вижу смысла решать эту проблему как-то «правильнее»; по-моему, это сродни графомании :) Может быть, вы хотели привести какой-то другой пример?

Да и саму концепцию целостности данных чуть ли не любой ценой (и как следствие — применение специальных архитектур, поддерживающих это специальными средствами) следовало бы воспринимать критически :) Понимаю, что для вас эта концепция сродни священной корове, но уж выскажу «ересь» :) Во-первых, очень часто это становится поперек горла пользователям, заставляя их поступать вопреки человеческой природе; люди легко справляются с неполными и нечеткими данными и не испытывают особенных неудобств от работы с ними, а концепция целостности требует от них быть предельно точными. В этом ключе высказывался известный, как он себя называет, interaction designer Алан Купер, выдвигая взамен data integrity концепцию data immunity. Во-вторых, существующие средства все равно не позволяют решить проблему целостности (целью которой является осмысленность) полностью. Недавно вот работал со словарем United List of Artists' Names, составляемого довольно крупной конторой Getty-чего-то-там. Догадываюсь, что они не на FileMaker его разрабатывают. Так вот, в словаре (там около 120 тысяч записей) из примерно 30 тысяч имен с диакритическими знаками 600 с лишним (около полутора процентов) записаны с ошибками; во всяком случае, использование знаков не соответствует документации. Мне пришлось это выяснить, ведь я переводил их специальные код в обычные буквы. Это не считая того, что у некоторых художников датой смерти указан 2030, а то и 9999 год (последний я еще могу понять, но вот первый меня озадачил :) Кроме того, видно, что происходит утрата информации; например, у живших давно художников даты рождения и смерти бывают известны неточно (это объективная неустранимая неточность и вообще-то она должна быть сохранена), а в записях они указаны точно, как если бы в них не было сомнений. Ссылочную целостность не проверял, но подозреваю, и там косяки.

Это солидный фонд с большими финансовыми возможностями и высококвалифицированным персоналом, причем по логике вещей словарь должен стать normative reference; между прочим, лицензия на использование словаря продается за деньги (хоть и небольшие). Ничего, живут с вполне заметной долей косяков в продукте. Почему же магазин или швейная фабрика, или городская газета должны всеми силами пытаться обеспечить себе какую-то необыкновенную поддержку data integrity для решения, в общем-то, несущественных проблем?

(OFF Однако, что-то я расписался; тоже ведь работать надо :) Если честно, я очень редко встречал в online-спорах людей, менявших свое мнение под воздействием аргументов противника. Если еще честнее, то в половине случаев это был я сам :) А так как составление реплик отнимает достаточно много времени, я, пожалуй, оставлю за собой право не продолжать эту дискуссию. Простите, пожалуйста :) /OFF)
30 авг 04, 21:25    [919808]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Рыжий Кот
Member

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

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

ограничения современной вычислительной техники - что вас ограничивает? Как говорится, не бывает технических проблем, бывают только организаторские.

Ваш пример, Михаил Едошин, про художников - это называется очепяткой.
Для базы нужно строить дежурные проверочные запросы (если на клиенте предотвратить ошибку сложно): выгрузки раньше погрузки, рождение позже смерти, подсумма не равна сумме, атрибут соответствующий предмету побывал у нас 20 раз со значением А, а на 21-ый раз пришел со значением В.
Оформляете это все в виде, скажем, Human Errors List (c) маё, и наблюдаете.

А вот файл-серверные технологии... Все-таки я больше тяготею ко мнению Злого, поскольку во-первых сам "спрыгнул" с таких решений, во-вторых
надежность клиент-сервера все-таки повыше, что бы там не говорили.

Про кукурузники и комкорды , есть замечательные такие ма-а-а-ленькие "комкордики", почти как кукурузники, только все равно комкордики, поищите, они есть...


Картинка с другого сайта.
30 авг 04, 21:57    [919821]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
При наличии вполне нормальных оупенсорсных СУБД, однозначно превосходящих Filemaker server по всем параметрам, я не могу понять людей использующих Filemaker. Средств для рисования окошек пруд пруди, причем независимых от БД. Не умеете писать SQL - есть куча всяких разных query builder'ов. Используйте нормальные СУБД а не технологии позавчерашнего дня.

Ну какое это к черту превосходство, если скорость разработки ниже, а вероятность ошибки, особенно при "не умении писать SQL" в несколько раз выше чем у ФМ? Заказчику же дороже встанет!

И зачем мне предлагать заказчику каке-то, по Вашим словам, "превосходящее" FileMaker Server СУБД? Ему нужно не ПРЕвосходящее, а ПОДходящее!

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

Откуда: Северная Калифорния
Сообщений: 686
Про кукурузник и конкорд отвечу простенько. И среди маленьких и среди больших (взлетный вес от 80-100 тонн) самолетов бывают удачные и неудачные конструкции. Если мерить удачность "рублем/долларом" то Конкорд - хрестоматийный пример неудачи. А АН-2 и сессна - удачные самолеты в своей нише, посему и распространенные. Все в конечном итоге упирается в практичность, то есть в деньги.

Очень рад что RAD и XP оказались в одном посте. ИМХО такой подход к решению задачи практичен только на первый взгляд. То есть действительно можно быстро "экстремально" что-то наваять. Только вот поддержка этого "чего-то" потом будет стоить непрактично дорого. А аномалии в данных - еще дороже. Filemaker и ему подобные продукты, вкупе с родстенной им идеологией разработки приводят вот к чему:
- вся логика на клиенте
- структура данных толком не продумана, ни логическая ни физическая
- надежных механизмов обеспечения целостности данных нет

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

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

Если кто-то хочет убедиться в том какой вред приносит перенос логики из базы в приложение, милости прошу в мир SAP и BAAN. Чистых и непротиворечивых данных в этих системах не бывает практически никогда. Разработчики этих систем заменили в свое время файлы на таблицы в БД но больше они не сделали ничего существенного. Логика как была в приложении, так и осталась. Аномалии в данных как были, так и остались. Производительность как была паршивой так и осталась, и более мощные железяки ее почему-то не лечат.

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

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

Приведу еще один пример: некое финансвовое уреждение хранило свою Accounts Receivables базу на IBMовской железяке с не-IBMовской базой данных. Бэкапы регулярно делались но ни разу не проверялись, ибо на вторую IBMовскую железяку денег не выделили. В один прекрасный момент на железяке "накрылся" диск - нично не вечно под луной. Восстанавливаются ребята с бэкапа и опаньки! После восстановления система ругается на corrupt данные и не хочет стартовать. Скандал, паника "разбор полетов" на повышенных тонах с IBM и производителем СУБД. Когда на 3й день главный IT дядька прибежал в кабинет к CEO с радостным криком "ура, восстановили" там шло обсуждение как фирма будет объявлять банкротство в случае если данные восстановлены не будут. В результате оказалось что был баг в драйвере девайса общающегося с лентой. Хорошо что баг вылезал при чтении а не при записи, иначе ребята бы "приплыли" капитально.

Все к чему - грязные данные это очень плохо, и в конечном итоге обходятся гораздо дороже чем кажется на первый взгляд. Многопользовательские системы с толстым клиентом - это однозначно грязные данные. Поэтому ИМХО экономить "на спичках" не стоит. Ну тут "каждый сам себе злобный баклан" как говорится.
31 авг 04, 00:33    [919872]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить