Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / FoxPro, Visual FoxPro Новый топик    Ответить
 Приемущества/недостатки CursorAdapter и OPEN DATABASE ..?  [new]
ilya_sql
Guest
Вопрос опытным программистам-практикам:
Какие приемущества/недостатки CursorAdapter и OPEN DATABASE .. методов в двух словах (приминительно к формализации задачи, построению внутренней структуры/процедур - чтобы в итоге приходилось делать меньше изменений при изменении бизнес-логики, бд)?

Думаю, что для многих начинающих этот вопрос будет крайне полезно рассмотреть перед тем, как приступать к проектированию ПО.
9 июн 04, 09:37    [730575]     Ответить | Цитировать Сообщить модератору
 Re: Приемущества/недостатки CursorAdapter и OPEN DATABASE ..?  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8873
Боюсь молодой человек, что про CursorAdapter Вам мало что смогут сказать практики - вещь эта новая и инородная в VFP. Пока очень мало документации и соответственно никто толком его и не применяет на практике. А некторые вещи в этом новом классе просто намертво вешеют FoxPro.

Лично я пытался применить его два раза и оба раза сдвавлся - добавлял четыре поля в таблицу - и все прокатывал на "ура", правда кода приходится писать больше, но в VFP это не проблема.

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

Вопрос про OPEN DATABASE мне не понятен. Хорошая команда - после нее нет необходимости указывать полные пути для команды USE (если Вы привыкли все держать под контролем). Аналогично для любителей DataEnvironment - VFP находит таблицы только по имени, даже если абсолютный путь был изменен. Кроме того - хранимые процедуры работают как родные (только не увлекайтесь последними в теле контейнера VFP - это вам не БД SQL Server).

P.S. Это всего лишь мое скромное мнение, не претендующее на истину.

Good Luck!
10 июн 04, 11:16    [734108]     Ответить | Цитировать Сообщить модератору
 Приемущества/недостатки CursorAdapter и OPEN DATABASE ..?  [new]
ilya_sql
Guest
Думаю, следует уточнить: под OPEN DATABASE .. имеется ввиду использование 'родных' локальных таблиц/представлений. В силу ограниченности данного подхода при определенном количестве пользователей ищется способ, при использовании которого не падала бы производительность.
Поэтому интересует оценка народа по теме?
10 июн 04, 14:17    [734884]     Ответить | Цитировать Сообщить модератору
 Re: Приемущества/недостатки CursorAdapter и OPEN DATABASE ..?  [new]
Sergey Ch
Member

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

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

Good luck!
11 июн 04, 10:56    [737004]     Ответить | Цитировать Сообщить модератору
 Re: Приемущества/недостатки CursorAdapter и OPEN DATABASE ..?  [new]
a
Guest
ilya_sql
Думаю, следует уточнить: под OPEN DATABASE .. имеется ввиду использование 'родных' локальных таблиц/представлений. В силу ограниченности данного подхода при определенном количестве пользователей ищется способ, при использовании которого не падала бы производительность.
Поэтому интересует оценка народа по теме?


можно про представления почитать

http://www.genrep.nm.ru/12step/12_step.htm
11 июн 04, 11:04    [737034]     Ответить | Цитировать Сообщить модератору
 Re: Приемущества/недостатки CursorAdapter и OPEN DATABASE ..?  [new]
BladeRunner
Member

Откуда:
Сообщений: 66
CursorAdapter - очень эффективное, хотя и громоздкое средство с ним просто долго разбираться - получаешь невнятные сообщения об ошибках или "мёртвые" курсоры, изменения в которых, например, не отражаются в таблицах. Хотя разобраться можно и добиваться при помощи них весьма и весьма неплохих результатов!
Простая ситуация - есть пара-тройка таблиц, несколько форм использующих эти данные, что делать? Не напрягая серое вещество в дизайнере локальных видов (Local view) в критериях отбора (Where) пришем что-то вроде ...
field_name = ?pcCondition
По определённому критерию содержимое выгребаем в вид и радуемся жизни, занеся это как Local View в базу данных.
А позже в коде ...
m.pcCondition = "Condition"
REQUERY("lv_MyView1")
Пока всё замечательно, НО! Ситуация усложняется - критериев несколько, они разные и условия выборок постоянно меняются, таблиц может быть в одном случае две, в другом три и т.д. (вариантов дерьма придумать можно много ...). Можно попытаться предугадать к-во вариантов - наклепать видов и изменять в зависимости от ситуации RecordSource в многострадальных Grid. А теперь добавим в форму CursorAdapter и посмотрим, что получилось и о чудо - НАМ НАПЛЕВАТЬ ОТКУДА МЫ БЕРЁМ ДАННЫЕ! Сегодня это локальная таблица и пара-тройка локальных видов (мы меняем лишь источники), завтра пяток удалённых видов, а послезавтра баловынные юзвери хотят запросную систему и мы даём им её примитивно и легко используя конкатенацию строк и настраиваемые возможности CA . А алиас всё продолжает как в первом, так во втором и третьем случаях назваться lv_MyView1!
На мой взгляд, вы неверно ставите вопрос - не нужно противопоставлять эти два механизма - нужно дополнять ими друг-друга облегчая себе жизнь.
Я лично сравнивал Native, ODBC и XML - в первом случае всё замечательно, как будто работаешь с локальным видом который ты создал в БД, во втором - если проходящий мимо компа юзверь не выдернул шнурок - то сервер тебе ответит )), ну а третье - перегруженный текстушник, он и есть перегруженный текстушник. Повторяю - НЕ ПРОТИВОПОСТАВЛЯЙТЕ CursorAdapter и собственно базу данных и ваши dbf-файлы друг - другу - ДОПОЛНЯЙТЕ!
Ну а что же до производительности - гы-гы - я видел собственным зрением, как грамотно составленный запрос на лисе (разумно и рацонально созданные индексы в таблицах с грамотной структурой) УДЕЛАЛ такой же запрос с SQL-серверу!!! Я видел и базу с суммарным объёмом записей порядка 1,5 - 2 миллионов записей (только в главной таблице к-во было порядка 500 - 700 тыс.), всё это хозяйство вертелось на НЕВЫДЕЛЕННОМ сервере, а цеплялось 20 - 25 пользователей и знаете - всё работало! Был это 98 год и лис версии 3. Да месячный отчёт по продажам делался минут 5 - 7, но в остальном всё быстро и удобно работало.
Мое личное мнение таково - не нужно гоняться за клиент-серверной технологией, масса задач даже файл-сервер не используют на полную (ну если какой недоносок не поставил на сервер ICQ и PhotoShop [и такое бывает]).

P.S.: Разбирался я по примерам, на разбор ушло несколько часов неспешного ковыряния.
14 июн 04, 02:17    [740356]     Ответить | Цитировать Сообщить модератору
Все форумы / FoxPro, Visual FoxPro Ответить