Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 23   вперед  Ctrl
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
Я попробую найти эту статью сейчас! Это было где-то перед новым годом!
Если найду, дам ссылку!
26 авг 04, 13:32    [910220]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
В этой статье не было речи об ФМ! Там было просто написано, что Майкрософт собирается выделить это количество денег для прграмм предназначенных в сферах среднего и малого бизнеса! Я попробую поискать эту статью. Если найду дам ссылку на нее. Я ее читал где перед началом 2004 года!
26 авг 04, 13:42    [910276]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Александр Зуев
Access всегда отставал от FM

IMHO, нет такой задачи, разработанной на Access, которую нельзя было бы повторить на FM, но не всякую задачу, разработанную на FM, можно повторить на Access.
26 авг 04, 13:47    [910312]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
В этой статье не было речи об ФМ! Там было просто написано, что Майкрософт собирается выделить это количество денег для прграмм предназначенных в сферах среднего и малого бизнеса! Я попробую поискать эту статью. Если найду дам ссылку на нее. Я ее читал где перед началом 2004 года!
26 авг 04, 14:03    [910404]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Guest_2
Guest
автор
Guest_2
Ну и где в Вашем примере структура БД?
Кхм... ну, собственно, на второй странице. :-)

Я вообще-то ожидал чего-то более подробного. Структура данных таблиц - отсутствует. Поэтому ничего определенного сказать о качестве структуры БД нельзя. :(

автор
Этой весной я делал систему авто-заполнения PDF-форм. Там данные брались через ODBC, а потом перегонялись в PDF-форму. Когда я закончил систему в ней было 120 различных типов навороченных PDF-форм с различными наборами полей. Позже заказчик самостоятельно собирался добавлять новые PDF-формы, поэтому пришлось разработать два специальных экрана - Field Mapping. Один для импорта из ODBC, второй для экспорта в PDF. Так вот там как раз и нужно было формировать произвольный Select по типу текущей PDF-формы. Пример скриншота этой системы лежит сдесь (STRS FMS.jpg).

Скриншот я посмотрел - красиво. Но Вы так и не рассказали о том насколько просто в ФМ можно реализовать произвольный SQL Select.

2 alfer_fm
Про Роберта Шекли мне понравилось. :-)
Давайте не будем трогать Delphi, я им не пользуюсь. Я действительно хочу выяснить для себя, насколько хорош ФМ в качестве средства быстрой разработки клиентской части для серверов SQL. Вот почему для меня важно как ФМ умеет работать с особенностями реализации SQL'я различных серверов. ODBC до сих пор остается пром. стандартом для доступа к реляционным СУБД и мне совершенно безразличны всякие прямые компоненты доступа. Для меня достаточно наличие ODBC драйвера к СУБД.

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

Расскажите про язык запросов ФМ. Как я уже понял - это не есть диалект SQL. Скорее всего что-то вроде QBE.

Существует ли ODBC драйвер для доступа к данным ФМ?
Каким образом я могу интегрировать данные ФМ в свою существующую ИС?
26 авг 04, 14:16    [910511]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
alfer_fm
Member

Откуда: Россия, Москва
Сообщений: 33
Guest_2
Я действительно хочу выяснить для себя, насколько хорош ФМ в качестве средства быстрой разработки клиентской части для серверов SQL. Вот почему для меня важно как ФМ умеет работать с особенностями реализации SQL'я различных серверов.


ФМ работает с ODBC точно также как и любое другое приложение, которое обращается к серверу через ODBC. Никакой экзотики тут абсолютно нет и быть не может. И особенность реализации SQL под конкретный сервер ни как не привязана к ФМ, это зависит от драйвера ODBC конкретной СУБД. Повторюсь, что при использовании хранимых процедур, пропадают и ограничения самого драйвера ODBC.

Guest_2

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


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

Guest_2

Расскажите про язык запросов ФМ. Как я уже понял - это не есть диалект SQL. Скорее всего что-то вроде QBE.


Я думаю про это более профессионально Саша Зуев напишет. :)

Guest_2

Существует ли ODBC драйвер для доступа к данным ФМ?


При установке ФМ в администраторе ODBC появляются следующие драйвера:
FileMaker Oracle8 Driver
FileMaker Pro (для доступа к ФМ)
FileMaker SQL Server Driver
FileMaker Text Driver
26 авг 04, 17:21    [911900]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Guest_2
Я вообще-то ожидал чего-то более подробного. Структура данных таблиц - отсутствует. Поэтому ничего определенного сказать о качестве структуры БД нельзя.

Да, пожалуй эта спецификация не подходит для человека, котрый вообще не знаком с ФМ, но опытный разработчик в состоянии по ней в точности воспроизвести описанную БД. Я уже года 4 делаю БД для американцев по таким спецификациям. Иногда даже бывает что я до конца разработки не знаю чем же на самом деле занимается заказчик... :-)

Вы так и не рассказали о том насколько просто в ФМ можно реализовать произвольный SQL Select.

В смысле, как в ФМ построить SQL-запрос? - В калькулируемом текстовом поле:

"Select " & ODBCFieldOne & ", " & ODBCFieldTwo & 
" From '" & ODBCTableName & 
"' Where " & ODBCKeyField & "= '" & <SomeValue> & "'"

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


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

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

Расскажите про язык запросов ФМ. Как я уже понял - это не есть диалект SQL. Скорее всего что-то вроде QBE.

В ФМ нет никакого языка запросов. Основной инструмент манипуляции записями - гибкая система построения реляционных связей. Для построения отчетов используется режим поиска с набором обычных операторов (<>=*@! и пр.) Этот же режим поиска может использовать и пользователь в процессе работы с базой данных. Запрос на поиск не формирует новую таблицу, а как бы делит текущую таблицу на две чати - найденные записи (отвечающие условию поиска) и скрытые записи (не отвечающие условию поиска). В процессе работы с таблицей пользователь может перемещаться на любую запись этой таблицы, если конечно его не ограничивают права доступа.

В многопользовательском режиме блокировка записей происходит автоматический. В ФМ 6 - при входе в поле, в ФМ 7 - при попытке редактирования. Разблокировка в ФМ 6 тоже происходит автоматически - при выходе из поля. В ФМ 7 разблокировка происходит либо автоматически, либо по команде Comit.

Каким образом я могу интегрировать данные ФМ в свою существующую ИС?

Вероятно через ODBC/JDBC или XML.
26 авг 04, 18:54    [912215]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

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


А я почему-то считал что опытные разработчики начинают с постановки задачи и семантического моделирования. То бишь выясняют, уточняют, стандартизируют и формализуют определения терминов из предметной области, которыми изъясняется заказчик. У буржуев такое называется умными словами типа Metadata и Data Dictionary. Потом делают концептуальную-логическую-физическую модели. Потом реализуют физическую модель на SQL (или IMS, filemaker, или еще на какой-нибудь технологии) . А уже потом пишут приложения. Эк я заблуждался. Оказывается все просто, берем, рисуем формы/отчеты потом по ним лепим какую-то структуру данных. А потом удивляемся откуда у нас в данных аномалии, фантомы, блокировки и прочая муть. Так шо, извиняйте батьку, "Александр Зуев". Обязуюсь забыть все что читал у Мартина, Дэйта, Кодда, и других авторов, а заодно и все чему научился в области проектирования БД за последние 15 лет. Рецепт счастья прост. И называется он ФайлМэйкер! А мы, провокаторы, зачем-то ковыряемся с Oracle, Teradata, MSSQL, SapDB/MaxDB, и всяким DB2 c Informix.

Файлмэйкер можно использовать как
1. Средство разработки клиентского приложения
2. Надстройку над файловой системой, понимающую SQL.

Насчет первого - вполне нормальное средство, вопросов нет. А по второму пункту - это, извините, нечто клиппероподобное. Его не то что с MSSQL, его даже с MySQL сравнивать не стоит. Я уж не говорю про PostGreSQL, Ingres, SapDB/MaxDB.

Поделку понимающую SQL и гоняющую его против файлов сделать может студент 3 курса технического ВУЗа. Полноценной СУБД она не будет. Точно так же полноценными СУБД не являются Клиппер, ФоксПро и им подобные. Ибо кроме блокировок на уровне записи полноценная СУБД умеет еще "вагон и маленькую тележку" того, что не умеют Клиппер с ФайлМэйкером, и никогда уметь не будут. От ACID транзакций до Hot Backup.
27 авг 04, 02:47    [912622]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
Вы очень критично относитесь к себе. Вы не провокатор. Вы просто любите делать из мухи слона и порой самую простую задачу пытаетесь решать с помощью ORACL, SQL. То есть для того, чтобы забить гвоздь Вы берете отбойный молоток, а потом выясняется, что нужен еще и компрессор. И в конце забиваете гвоздь так, что его потом не вытащишь, не поправишь. Надеюсь Вы понимаете к чему я это говорю. Я достаточно хорошо знаком с возможностями SQL SERVER 2000 (с прекрасными возможностями). Хвала Вам, что разобрались и с ORACLE. Но это не дает Вам право смотреть на Все остальное с высока и с пренебрежением, и "гнать всех в шею". Вы должны согласиться с тем, что для простенькой бухгалтерии среднего и малого бизнеса, а таковыми являются вероятно 98 % Российского рынка, нет смысла запускать такую махину, как ORACL и SQL. Отсюда и идут все беды типа заплатил 15000 долларов за программу, а теперь плати 300 долларов за обслуживание. А через 3-4 года заявление о том, что "Мы создали новую программу, она стоит уже 40000 долларов, а старую будем обслуживать максимум еще один год". Умный руководитель думаю возьмет своего программиста и изберет такое средство автоматизации, которая позволяет делать все быстро и динамично.
Речь совсем не идет о том, что плоха та СУБД и хороша эта СУБД. Речь идет о том где и что применять. Прямо во время работы сети, в которой явлются активными до 30 пользователей, вдруг делается команда об изменении вида счета-фактуры для клиента, ожидающего поставляемый товар, и всякие другие изменения в работе программы в динамическом режиме. Поверьте, что все это исполнимо в ФМ без остановки работы всей сети и выключения программы. Да и поверьте, если Вы собираетесь далее зарабатывать себе на хлеб Вы рано или поздно перейдете на ФМ или что-либо подобное. Вы человек, как я понял, достаточно умный.... просто немного погорячились. Да оно и видно, что уже Вам сзади "наступают на хвост", поэтому так категорично Вы отзываетесь "о всяких там файлмейкеровцах". Но бояться Вам ничего не следует. У Вас достаточно ума! Вы разберетесь в ФМ и будете на нем работать ( если захотите кушать). Вспомните как развалилась Римская империя со своей огромной армией. Вспомните как трудно затащить ребенка первый раз в воду. Зато потом его оттуда не вытащишь.
27 авг 04, 09:26    [912883]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Вы должны согласиться с тем, что для простенькой бухгалтерии среднего и малого бизнеса, а таковыми являются вероятно 98 % Российского рынка, нет смысла запускать такую махину, как ORACL и SQL.

Не согласен - нет простенькой бухгалтерии для малого и среднего бизнеса. Есть ужасный и запутанный Трудовой и Налоговый кодекс, которым почхать, маленький бизнес или нет и которые не делают бухгалтерию простенькой. А еще есть понятие масштабирования, когда мелкий бизнес может вырасти до уровня крупного и там где работало 5 пользователей и БД весила 1 мб уже работает куча народу, удаленно крутятся филиалы и еще много чего еще вдруг появляется. И не понятно, почему Вы РСУБД называете махинами - возьмите себе ту же недорогую Sybase ASA и пишите проекты на здоровье, сильно это цену проекта не увеличит, администрирования у клиента она не потребует, к железу тоже особых требований не будет. А клиента можно на чем угодно написать - хоть на Filemaker, хоть на PowerBuilder, хоть на Delphi, тут уже кому что выгодней окажется.
27 авг 04, 09:59    [912990]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
alfer_fm
Member

Откуда: Россия, Москва
Сообщений: 33
Зл0й
автор Александр Зуев
Опытные разработчики начинают проектирование БД ФМ с отрисовки основных экранов "клиентской части".


А я почему-то считал что опытные разработчики начинают с постановки задачи и семантического моделирования. То бишь выясняют, уточняют, стандартизируют и формализуют определения терминов из предметной области, которыми изъясняется заказчик. У буржуев такое называется умными словами типа Metadata и Data Dictionary. Потом делают концептуальную-логическую-физическую модели. Потом реализуют физическую модель на SQL (или IMS, filemaker, или еще на какой-нибудь технологии) . А уже потом пишут приложения. Эк я заблуждался. Оказывается все просто, берем, рисуем формы/отчеты потом по ним лепим какую-то структуру данных. А потом удивляемся откуда у нас в данных аномалии, фантомы, блокировки и прочая муть. Так шо, извиняйте батьку, "Александр Зуев". Обязуюсь забыть все что читал у Мартина, Дэйта, Кодда, и других авторов, а заодно и все чему научился в области проектирования БД за последние 15 лет. Рецепт счастья прост. И называется он ФайлМэйкер! А мы, провокаторы, зачем-то ковыряемся с Oracle, Teradata, MSSQL, SapDB/MaxDB, и всяким DB2 c Informix.


:)) Откровенно говоря так и подмывает ответить Вам фразой Юрия Никулина из фильма "Когда деревья были большими": "Отстань, отстань - это манера. Манера у меня такая". Потому как мы вроде пытаемся убедить, что ФМ не такая уж и гадость :) и нам он нравится, и не отвергаем мы другие средства разработки. А с Вашей стороны иногда попахивает борьбой с инакомыслием :))
Просто ФМ так позволяет проектировать программу (как написал Саша), но никто не мешает сначала создать модель, а потом уже "нарисовать" клиентскую часть. Но клиенту-заказчику, как правило, проще наоборот. Проще нарисовать, чего у него должно быть перед глазами, в процессе этого и выявляется из чего собственно должна состоять база (какие справочники, поля, какие отчёты и др.). А потом уже разработчик и работает по той схеме, о которой Вы говорите. ИМЕННО ФМ ТАК ПОЗВОЛЯЕТ ДЕЛАТЬ.
Так что ничего страшного я тут не вижу.
Ну не нравится Вам ФМ, по Вашим соображениям, ну не пишите на нём, учитывая сильное желание скрестить его с каким-либо сервером SQL. Но вот унижать продукт только за то, что он не похож на другие, с высоты Вашего опыта, не очень красиво. Даже если это Клиппер или ФоксПро. Мы ведь все из этого выросли, и хуже от этого никому не стало. :)
27 авг 04, 11:03    [913265]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
alfer_fm
Member

Откуда: Россия, Москва
Сообщений: 33
Зл0й
автор Александр Зуев
Опытные разработчики начинают проектирование БД ФМ с отрисовки основных экранов "клиентской части".


А я почему-то считал что опытные разработчики начинают с постановки задачи и семантического моделирования. То бишь выясняют, уточняют, стандартизируют и формализуют определения терминов из предметной области, которыми изъясняется заказчик. У буржуев такое называется умными словами типа Metadata и Data Dictionary. Потом делают концептуальную-логическую-физическую модели. Потом реализуют физическую модель на SQL (или IMS, filemaker, или еще на какой-нибудь технологии) . А уже потом пишут приложения. Эк я заблуждался. Оказывается все просто, берем, рисуем формы/отчеты потом по ним лепим какую-то структуру данных. А потом удивляемся откуда у нас в данных аномалии, фантомы, блокировки и прочая муть. Так шо, извиняйте батьку, "Александр Зуев". Обязуюсь забыть все что читал у Мартина, Дэйта, Кодда, и других авторов, а заодно и все чему научился в области проектирования БД за последние 15 лет. Рецепт счастья прост. И называется он ФайлМэйкер! А мы, провокаторы, зачем-то ковыряемся с Oracle, Teradata, MSSQL, SapDB/MaxDB, и всяким DB2 c Informix.

Файлмэйкер можно использовать как
1. Средство разработки клиентского приложения
2. Надстройку над файловой системой, понимающую SQL.

Насчет первого - вполне нормальное средство, вопросов нет. А по второму пункту - это, извините, нечто клиппероподобное. Его не то что с MSSQL, его даже с MySQL сравнивать не стоит. Я уж не говорю про PostGreSQL, Ingres, SapDB/MaxDB.

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


Ещё раз перечитал Ваш пост. Извините за резкость, но Вы, к сожалению, ВООБЩЕ НЕ ПОНЯЛИ ЧТО ТАКОЕ ФМ! Какая "надстройка над файловой системой"! ФМ - это полноценная СУБД, да, внутри себя она не испольует SQL, что ж теперь застрелиться что-ли? От этого она работает не хуже, просто так реализовано. Всё зависит от механизма реализации запросов. Вот в MS Access можно пользоваться мастером запросов, а можно просто писать "select * from...", так что же теперь молиться на Access что ли?

Я был на семинаре Cache и видел как плевались крутые спецы по SQL, мол дайте нам тесты где было бы видно, что Cache работает быстрее Oracle. А им объясняли, что Cache на SQL не обязательно будет работать быстрее Oracel, это будет так только при использовании внутреннего языка Cache. А перенесение базу "в лоб" с сервера на сервер ничего не даст. Так что ж теперь, Cache - полный отстой что ли, раз SQL - это не самое сильное его место?
27 авг 04, 11:33    [913422]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Гость очередной
Guest
Не согласен - нет простенькой бухгалтерии для малого и среднего бизнеса. Есть ужасный и запутанный Трудовой и Налоговый кодекс, которым почхать, маленький бизнес или нет и которые не делают бухгалтерию простенькой
Вы меня не так поняли. Простенькой я называю ту бухгалтерию, в которой до 1-5 млн операций в год, (да и это для ФМ не предел) а не ту, в которой нет законов.На Российском рынке я думаю мало предприятий работающих в таком массшатабе. Да и не только на Российском, но и на любом иностранном. Потому и все большая и большая популярность ФМ ! Тут спору нет! Скажу что эта СУБД преподается в 49 из 51 университетов США.
27 авг 04, 11:58    [913560]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Михаил Едошин
Guest
Зл0й
А я почему-то считал что опытные разработчики начинают с постановки задачи и семантического моделирования. То бишь выясняют, уточняют, стандартизируют и формализуют определения терминов из предметной области, которыми изъясняется заказчик. У буржуев такое называется умными словами типа Metadata и Data Dictionary. Потом делают концептуальную-логическую-физическую модели. Потом реализуют физическую модель на SQL (или IMS, filemaker, или еще на какой-нибудь технологии) . А уже потом пишут приложения. Эк я заблуждался. Оказывается все просто, берем, рисуем формы/отчеты потом по ним лепим какую-то структуру данных. А потом удивляемся откуда у нас в данных аномалии, фантомы, блокировки и прочая муть. Так шо, извиняйте батьку, "Александр Зуев". Обязуюсь забыть все что читал у Мартина, Дэйта, Кодда, и других авторов, а заодно и все чему научился в области проектирования БД за последние 15 лет. Рецепт счастья прост. И называется он ФайлМэйкер! А мы, провокаторы, зачем-то ковыряемся с Oracle, Teradata, MSSQL, SapDB/MaxDB, и всяким DB2 c Informix.


Судя по вашей любви к авторитетам, вам понравится цитата из Фредерика Брукса, «The Mythical Man-Month» (думаю, нет необходимости представлять автора и книгу):
автор Фредерик Брукс
Под архитектурой системы я понимаю полную и подробную спецификацию интерфейса пользователя. (курсив мой).

Контрастирующим понятием у Брукса является «реализация»; разумеется, «архитектура» ей предшествует.
Изложенная вами методология на самом деле очень часто описывается в солидных руководствах по разработке СУБД; но почему бы не вспомнить, что по статистике лишь около трети проектов, разрабатываемых по подобной схеме завершается в срок и не выходит за рамки бюджета? А довольно большая часть проектов вообще прекращается! «Гладко было на бумаге…» А есть ведь и принципиально другие методологии, например, «экстремальное программироване», где планы специально пишут на маленьких карточках, чтобы не провоцировать их разрастания и принимают специальные меры, чтобы не делать ничего сверх необходимой функциональности (читай — интерфейса пользователя).
Да и так поразмыслить: а отчего, скажите, вы так уверены, что сможете разработать непротиворечивую модель системы, ни разу не показав пользователю того, что он может понять? Почему вы думаете, что можете разработать структуру данных без форм и отчетов, то есть, по сути, не зная, как они будут обрабатываться? Сесть и, анализируя проблему чисто теоретически (составляя словарь данных и т. п.), правильно решить ее? (Это невозможно, между прочим, прежде всего по философским соображениям; критерий истины — практика.) Впечатление вы, конечно, произведете. По моему собственному опыту заказчики при виде ER-диаграмм или спецификаций таблиц только ошалело кивают. А вот когда дело доходит до реальной работы, выясняются неприятные подробности. Чаще всего такой проект заканчивается или полной неудачей, или лихорадочным «хаканьем» всей концептуально-логической модели (тоже неудачей), или втискиванием того, что на самом деле нужно пользователю в прокрустово ложе написанной системы (как правило, содержащей при этом массу не особенно нужных возможностей; опять-таки неудачей).
Я и сам наступал на эти грабли (и на другие, на проблемы во время интеграции системы), больше не хочу. Я не говорю, что не буду составлять словарь данных, диаграммы «сущность-связь» и т. п.; но это всегда будут мои личные наброски, нужные только для более глубокого понимания задачи. Общаться же с клиентом я буду только с моделями реальной программы, т. е. с моделями интерфейса.
27 авг 04, 13:08    [913948]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
alfer_fm
Member

Откуда: Россия, Москва
Сообщений: 33
Михаил Едошин
Зл0й
А я почему-то считал что опытные разработчики начинают с постановки задачи и семантического моделирования. То бишь выясняют, уточняют, стандартизируют и формализуют определения терминов из предметной области, которыми изъясняется заказчик. У буржуев такое называется умными словами типа Metadata и Data Dictionary. Потом делают концептуальную-логическую-физическую модели. Потом реализуют физическую модель на SQL (или IMS, filemaker, или еще на какой-нибудь технологии) . А уже потом пишут приложения. Эк я заблуждался. Оказывается все просто, берем, рисуем формы/отчеты потом по ним лепим какую-то структуру данных. А потом удивляемся откуда у нас в данных аномалии, фантомы, блокировки и прочая муть. Так шо, извиняйте батьку, "Александр Зуев". Обязуюсь забыть все что читал у Мартина, Дэйта, Кодда, и других авторов, а заодно и все чему научился в области проектирования БД за последние 15 лет. Рецепт счастья прост. И называется он ФайлМэйкер! А мы, провокаторы, зачем-то ковыряемся с Oracle, Teradata, MSSQL, SapDB/MaxDB, и всяким DB2 c Informix.


Судя по вашей любви к авторитетам, вам понравится цитата из Фредерика Брукса, «The Mythical Man-Month» (думаю, нет необходимости представлять автора и книгу):
автор Фредерик Брукс
Под архитектурой системы я понимаю полную и подробную спецификацию интерфейса пользователя. (курсив мой).

Контрастирующим понятием у Брукса является «реализация»; разумеется, «архитектура» ей предшествует.
Изложенная вами методология на самом деле очень часто описывается в солидных руководствах по разработке СУБД; но почему бы не вспомнить, что по статистике лишь около трети проектов, разрабатываемых по подобной схеме завершается в срок и не выходит за рамки бюджета? А довольно большая часть проектов вообще прекращается! «Гладко было на бумаге…» А есть ведь и принципиально другие методологии, например, «экстремальное программироване», где планы специально пишут на маленьких карточках, чтобы не провоцировать их разрастания и принимают специальные меры, чтобы не делать ничего сверх необходимой функциональности (читай — интерфейса пользователя).
Да и так поразмыслить: а отчего, скажите, вы так уверены, что сможете разработать непротиворечивую модель системы, ни разу не показав пользователю того, что он может понять? Почему вы думаете, что можете разработать структуру данных без форм и отчетов, то есть, по сути, не зная, как они будут обрабатываться? Сесть и, анализируя проблему чисто теоретически (составляя словарь данных и т. п.), правильно решить ее? (Это невозможно, между прочим, прежде всего по философским соображениям; критерий истины — практика.) Впечатление вы, конечно, произведете. По моему собственному опыту заказчики при виде ER-диаграмм или спецификаций таблиц только ошалело кивают. А вот когда дело доходит до реальной работы, выясняются неприятные подробности. Чаще всего такой проект заканчивается или полной неудачей, или лихорадочным «хаканьем» всей концептуально-логической модели (тоже неудачей), или втискиванием того, что на самом деле нужно пользователю в прокрустово ложе написанной системы (как правило, содержащей при этом массу не особенно нужных возможностей; опять-таки неудачей).
Я и сам наступал на эти грабли (и на другие, на проблемы во время интеграции системы), больше не хочу. Я не говорю, что не буду составлять словарь данных, диаграммы «сущность-связь» и т. п.; но это всегда будут мои личные наброски, нужные только для более глубокого понимания задачи. Общаться же с клиентом я буду только с моделями реальной программы, т. е. с моделями интерфейса.


Золотые слова! :)
AndrEw ;)
27 авг 04, 13:31    [914097]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Dedushka Mazai
Member

Откуда:
Сообщений: 959
а мне вот что понравилось:
alfer_fm
Те кто используют SQL-сервера, зачастую НЕ ЗНАЮТ что такое ФМ вообще, а те кто пишет на ФМ, ЕЩЁ не совсем знают и понимают, что такое FileMaker 7 и FileMaker Server 7... Это фактически и есть полноценный клиент-сервер, даже команда Commit появилась.

в новых версиях файлмэйкера ожидается появление таких комманд, как StartTransaction и Rollback
27 авг 04, 17:12    [915271]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Значится так, начнем с проектирования БД. Объяснять буду "на пальцах" ибо времени писать философские трактаты нету. У любого клиента, деятельность (бизнес-процесс) которого мы пытаемся автоматизировать, информация УЖЕ хранится. Или на бумаге, или в виде кучи электронных таблиц, или еще в какой-нибудь форме, зарубки там на деревяшке, узелки "на память". Но как-то клиент информацию хранит. Как правило, если в процессе хранения и обработки этой информации участвует более 1 человека, нет общей оговоренной терминологии. Все вроде-как "понимают", но все понимают по своему. Приходит начальник к Петрову и говорит "подать мне outstanding balance" по выданным кредитам. Петров насчитал 2 миллиона рублей, а Сидоров лимон 800 тыщ. Ибо Петров "плохие" (просроченные) кредиты включил, а Сидоров - нет. Как с этим бороться:
- собрать и проанализировать ВСЕ способы которыми клиент хранит информацию относящуюся к бизнес-процессу. От зарубок на деревяшке и записок на posted notes до электронных таблиц и БД.
- систематизировать информацию, выработать четкие формальные определения типа "outstanding balance = сумма балансов по кредитам, кроме кредитов просроченных на 60 клендарных дней и более".
- довести эту систематизированную информацию до всех участников бизнес-процесса.

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

Теперь мы, разрисовываем и расписываем как же происходит бизнес-процесс. Потом, совместно с руководством ответственным за энтот процесс, садимся и смотрим можем ли мы его оптимизировать. Ибо создавать новую систему под старый, идиотский бизнес-процесс, который "исторически сложился" малопродуктивно - выйдет уродец. Обычно на данной стадии возникают "открытия" типа "ЁКЛМН, так вот почему...", "Блин, так вот как мы это делаем, а я то думал..." или вообще "а какого ... мы это делаем через ...?!!!". Покончив с хлопанием себя по лбу, восклицаниями, Охами и АХами, мы с руководством клиента садимся рисовать оптимизированную версию бизнес-процесса. Например раньше для выдачи кредита мы заколачивали данные в клиент-серверную систему, потом когда принято решение кредит выдать из нее распечатывали бумажную форму, которую посылали по интероффисной почте в другой город, где ея сновья (с ошибками) заколачивали в мэйнфреймовую бухгалтерскую систему учета кредитов, написанную еще во времена президента Никсона. Вместо этого уродливого и фантастически неэффективного бизнес-процесса мы делаем новый. Получаем всевозможные одобрения от руководства в письемнной форме.

Еще раз прошу заметить, что мы еще даже не приступили к рисованию ER-диаграмм, надуванию щек, итп. Но впечатление на клиента уже произвели.

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

И только когда задача толком поставлена, четко и формально, оговорена терминология итд. итп. мы начинаем "собственно программирование". Концептуальная модель у нас выходит с пол-тычка, ибо все уже формализовано, разжевано и в рот положено, осталось только проглотить. Затем логическая (нормализация там, первичные-вторичные ключи итп.), потом физическая (как хранить будем heap-таблицы, кластеры, индекс-организованные таблицы, партиции, индексы, итд. итп.). Потом пишем ХП, триггеры и всю процедурную реализацию бизнес-логики. Когда база сделана и оттестирована, к ней можно привесить всякие разные приложения. Например одно клиент-серверное и одно веб-приложение. Но приложения и отчеты делаются в последнюю очередь. Если база сделана грамотно, и вся бизнес-логика в ней, то приложения и отчеты пишутся и сопровождаются легко и непринужденно.

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

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

Про файл-мэйкер и полноценный клиент-сервер, приведу цитату из русского классика: "не пой красавица при мне...". Полноценный сервер СУБД начинается где-то в районе Oracle 6, и всяких Сайбэйсов и Информиксов примерно того же периода. Скажем 5й Оракл ИМХО современным представлени о "полноценном" сервере СУБД не соответствует. Как не соответствуют им MySQL, всевозможные надстройки над файловой системой понимающие (и не понимающие) SQL. Даже PostGreSQL "полноценным" считаю с натяжкой, из-за необходимости постоянно делать vacuum в OLTP-системах (кто этого зверя админил поймет о чём я, очень грубо говоря "сборка мусора" на диске). Я бы расписал что представляет собой полноценная СУБД, да мне идти работать надо. Плюс меня фанаты MySQL и PostGreSQL живьем съедят.

Напоследок выскажу такую мысль: даже зачуханные MySQL и PostGreSQL лучшее решение чем ФайлМэйкер и Клиппер. MSSQL, если религия позволяет, тоже лучше. MaxDB и Ingres тоже лучше. И дело тут вовсе не в SQL. А в том, что есть приличный запас куда расти и вообще решение гораздо более грамотное со всех точек зрения.
27 авг 04, 20:59    [915661]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
начнем с проектирования БД. Объяснять буду "на пальцах"

Доходчиво. Всё, в плоть до того места, где Вы начинаете "собственно программирование". Там у Вас потом идет целый абзац какой-то оракловской бредятины про heap-таблицы, кластеры и партиции. Зачем Вы вставили кучу платформенно-зависимой терминологии в описание общего стандарта программирования - непонятно, ну да Бог с ним. Но скажите на милость, для чего всё это? Сдесь же не детский сад! Люди вроде опытные собрались - понимают что из пальца БД не высосешь, что нужно сначала с заказчиком посидеть. Я, в своем описании технологии разработки БД на ФМ, эту часть опустил, а Вы зачем включили?

начинать проектирование с клиентского приложения это - ЕРЕСЬ

Спор слепых с глухими продолжается. Повторяю второй раз. Больше повторять не буду. Если рядом с Вами есть хоть один зрячий человек, попросите его п-ста прочесть Вам в слух следующее: В ФМ нет разделения межу клиентской и серверной частями. Разработав клиентскую часть Вы автоматически получаете серверную.

Про файл-мэйкер и полноценный клиент-сервер, приведу цитату из русского классика: "не пой красавица при мне..."

Я подсел на ФМ в конце девяностых годов, когда в нем даже намека небыло на клиент-серверную архитектуру. Подсел потому, что понял, что могу просто, быстро и качественно разработать на нем любую БД, что потом она будет работать устойчиво и будет иметь максимально простые средства администрирования. А какой термин будут использовать чтобы охарактеризовать принципы её работы - мне всегда было глубоко наплевать. С выпуском седьмой линии продуктов ФМ перешел на клиент-серверную архитектуру. Насколько полноценным клиент-сервером он стал - лично мне всеравно. Работать стал лучше? Появились новые фьючи? Исправили старые баги? Да? Ну так называйте как хотите!
28 авг 04, 17:00    [916140]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
Зл0й
MySQL и PostGreSQL лучшее решение чем ФайлМэйкер

Да?! Ну и чем же они лучше? Только конкретно п-ста. Про "грамотность" - не стоит, мы не на экзаменах. А вот тему роста можно было бы и развить. А то Ваше голословное утверждение пока как-то неубедительно звучит.
28 авг 04, 17:24    [916149]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Пользователь
Member [заблокирован]

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

Теперь мы, разрисовываем и расписываем как же происходит бизнес-процесс. Потом, совместно с руководством ответственным за энтот процесс, садимся и смотрим можем ли мы его оптимизировать.

Все вышеизложенное - весьма неполное (и местами неточное) изложение того как правильно делать автоматизацию.

Говорят - так нельзя создать непротиворечивую модель,
Говорят - так уже не модно,
Говорят - так не работает R3,
Говорят - надо сразу создать (подобрать ) идеальную модель, а из нее уже все вырастить.

Что Вы об этом думаете?
28 авг 04, 20:47    [916255]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Сильная фраза:
Разработав клиентскую часть Вы автоматически получаете серверную.
Я вот тут думал как мне структуру счетов сделать, остатков, чего нормализовывать, а что нет, чтоб оно побыстрее работало, а оказывается надо было взять FM, на нём сделать интерфейс, а серверная часть сама бы как надо сделалась. Не знал что доживу до таких времён.
Объясните - как этот чудесный FM работает, напишите хоть что-то про его принципы и концепции работы на нём? А то всё только голословные заявления (в общем-то что написал Зл0й никто обоснованно опровергнуть не смог ) что мы мол неправильно работаем, в FM можно все делать не так. Я не спорю, бывают нужны такие программы, где из интерфейса сразу ясно какая должна быть структура БД, но они на любом средстве разрабатываются быстро.
29 авг 04, 00:45    [916345]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
SergSuper
Объясните - как этот чудесный FM работает

Вот сдесь я выложил несколько скриншотов с описанием процесса создания примитивной, двух-табличной БД на ФМ. Почитайте, может это даст Вам какое-то представление о работе в ФМ.
29 авг 04, 16:56    [916549]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
как я понял что-то вроде многоплатформенного Асцесса.
а есть ли там триггеры, что-нибудь вроде хранимых процедур или всё это SQLная бредятина?
29 авг 04, 18:58    [916583]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
Александр Зуев
Guest
SergSuper
а есть ли там триггеры, что-нибудь вроде хранимых процедур

Поверите или нет, нет там никаких триггеров (которые, кстати, ФМ-разработчики клянчат у ФМИнк уже много лет), хранимыми процедурами там и не пахнет, а к SQL это всё вообще никакого отношения не имеет. Это - просто работает, а как?... Они не публикуют никакой информации ни о формате файлов, ни о сетевом протоколе. Есть только данные о производительности: предельное кол-во файлов (пакетов таблиц) на один сервер - что-то около 100 или больше; кол-во таблиц на файл - не ограничено; размер таблицы - не ограничен; кол-во записей на таблицу - не ограничено; предельный размер поля - 2ГБ (касательно текстовых полей или полей-контейнеров, позволяющих хранить текст, графику, видео, или просто файл неопределенного типа целиком). Я, недавно, ещё на ФМ6, делал для одной простенько БД прибамбаху - выбор адреса из КЛАДР. Ну, в общем, импортировалась эта хламида несколько часов, а потом, когда ФМ все индексы построил - выбор из БД на 500 тыс. записей занимал секунд 20.

А на счет того, кто "правильно" работает - глупость всё это. Вы видели когда-нибудь чтоб моряк учил летчика ходить? ФМ - это ФМ, Оракл - это Оракл. На ФМ - быстрее долетишь, на Оракле - больше довезёшь, - ну %ули спорить?
29 авг 04, 22:07    [916680]     Ответить | Цитировать Сообщить модератору
 Re: Filemaker брррр...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Александр, если б все такие задачи были простые как КЛАДР...
Ну возьмём для примера её. Допустим мне надо по вводимому адресу строчкой проверить корректный ли он. Интерфейс простой: есть строка редактирования, когда курсор с неё уходит при некорректном адресе появляется предупреждение об этом.
Итак вы создали этот интерфейс и получили прибамбаху? Есть у меня смутные сомнения...
Когда я у себя реализовывал базу адресов, я думал до какой степени надо нормализовывать, должна ли оставаться связи с данными из НИ, какие другие приложения смогут её использовать, чем мне жертвовать - производительностью или местом на диске и т.д. Заметьте что все эти вопросы не касаются именно SQL - это общие вопросы хранения данных. Вы хотите сказать что все их за меня решит ФМ? Опять же смутные сомнения...
Я пытаюсь понять как же это решается на ФМ, но в ответ моряк с лётчиком. Мол всё круто, но вам не понять. Я не прошу меня учить, мне просто интересно какие есть еще концепции работы с данными. Ссылку которую Вы привели - ну извините, ну это же полный примитив, примерно такое есть в любом средстве работы с БД.

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

Ну и напоследок не могу не придраться к фразе: выбор из БД на 500 тыс. записей занимал секунд 20. :)
Какой выбор? Куда? По каким условиям? Если поиск одной записи - как ни крути очень долго, если всей базы - то вроде незачем
30 авг 04, 01:34    [916727]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 23   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить