2Crip:
Ерунду вы говорите...
да ну! VB - никогда ООП языком не был. Так что речь не о нем
VFP - ООП язык? Т.е. там есть полиморфизм/инкапсуляция, наследование?
Классы с объектами? Если есть тогда да - я не прав и то что я сказал к VFP не относится.

Тогда другая проблема - предоставляема архитектура распределенных приложений - как здесь дела у VFP?

2Crip:

В общем-то я веду просто теоретический анализ - ничего более. Я очень плохо знаком с FoxPro!
Насчет C++ - не ООП - это теоретическое словоблудие.

Вопрос - в VFP есть классы/наследование? если да то вопрос снимается

Далее качательно распределенной архитектуры - насколько мастабируем VFP - можно ли распределять компоненты для повышения производительности/надежности.

Затем насчет SQL - это декларативный язык, т.е. в нем указываешь что получить, а не как. Так вот оказалось что это очень удобно при работе с данными. Разве нет?

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

Еще мнение - если на VFP начать писать как на ООП - то исчезнет сам VFP.
Т.е. я хочу сказать что фича VFP - это именно его работа с данными - а она у него носит "курсорный" характер

Далее вопрос, как в VFP дело с транзакциями? т.е. как они вообще там возможны если нет центра и все клиенты равноправны?

А ссылочная целостность?

Насчет ООП. Там есть полиморфизм - значит и позднее связывание?

2NNN: меня не надо переубеждать - я ничего не утверждаю - просто задаю вопросы.

Насчет Variant - это конечно смешно - но вопрос это ни в чью сторону не решает

2Crip: ответь последовательно на мои высказывания - что ты про каждое думаешь?

насчет позднего связывания - это то без чего не может работать полиморфизм. В C++ его обеспечивают виртуальные функции

Что ты думаешь про фразу Мюллера - разве не очень удачное сравнение?

Лень клаву ломать
нашел что жалеть!

Ты опять видишь только то что тебе надо! Вот самое важное
1) декларативный язык SQL - более "удобное" средство работы с данными
2) VFP больше похож на конструктор - сделай СУБД сам
3) Можно ли применять ООП на фоксе эффективно и в то же время не изменять его идеологии работы с данными
4) Робер Мюллер и паровоз (советую все-таки вникнуть, а то в стереотипах можно будет обвинять уже не только любителей РСУБД)
5) место файловых БД( как впрочем и РСУБД/ОРСУБД/ООСУБД ) в жизни. А также чем все-таки не нравится РСУБД - т.е. есть ли очевидные преимущества

P.S. мой взгляд на СУБД - подсистема, обеспечивающая хранение устойчивых объектов - соответствует ли это идеологии фокс про?

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

Работу с данными на фоксе можно построить и через SQL, и через команды,
доставшиеся в наследство еще с DOS версий. Старые команды существенно
быстрее, но это не критично - скорости вполне хватает. Однако, если в качестве
рабочих станций у вас стоят 486-е - лучше, конечно Seek(), чем Select
Я даю тезисы - вы или соглашаетесь или опровергаете их - зачем мне рассказ про то что на VFP можно использовать SQL - я это знаю.

А как связаны ООП и идеология работы с данными? Или, по вашему,
T-SQL является объектно-ориентированным языком?
Не смешивайте базу данных и средство разработки бизнес-логики
и пользовательского интерфейса.
Чувак, это твои проблемы если везде мерещатся ламеры. Я где-то сказал что TSQL - ООП? А насчет того как OOD и R-модели связаны - ну так это надо книжек вам почитать - а не соваться с выводами куда не просят

Пардон, моих мозговых усилий не хватает для постижения глубины этой мысли.
Это не мои проблемы

Учетные и информационные системы с количеством пользователей
в пределах сотни, работающие в локальной сети.
Так же фокс может с успехом использоваться для локальной
(на одном компьютере) обработки больших объемов данных.
Интересно, а если взять тот же FB или MySQL - какие экономические выгоды будет иметь разработчик на фоксе?


Есть примеры Интернет-приложений на Фоксе. См. например,
сайт www.universalthread.com, или читайте сообщения Sergey Ch.
Но это скорее экзотика.
Это еще мягко сказано. Да и потом это примеры серверных компонент - а та же .Net и Java обеспечивают возможность выполнения кода в небезопасной среде

2Crip:
Опять скатились до поучания.
Я Вас нигде ничему не поучал. Наоборот - было выдвинуто предположение о том что я считаю TSQL объектно-ориентированным языком.

Вообще-то ИМХО очень удобно писать бизнес-логику и интерфейс на ООП, а с данными работать через SQL.
Кстати по поводу SQL и ООП. Вся работа с данными в моем нынешнем приложении ведется именно через соответствующие классы, только внутри соответствующих методов встречаются нужные мне операторы DML/DDL

Лично я согласен (т.е. вижу рациональное зерно) и тоже считаю что это верный путь, НО это очень поверхностная трактовка распределенной системы с участием БД. Да есть классы - но это не значит что все методы это методы классов. Да и вообще распределение обязанностей между различными узлами системы - это и есть цель и профессионализм. В настоящее время существует огромное количество аспектов которые необходимо при этом учитывать. Т.е. два стереотипа/крайности (клиент-сервер и многоуровневое приложение)- это для начинающих и особо верующих. На самом деле нужно уметь распределять операции между этими уровнями. Например существует целый класс операций которые нежелательно иметь на сервере БД(и наоборот)

Возвращаясь к вопросу: если у вас внутри только DML/DDL - да еще и применительно к VFP(Т.е. не SQL) - тогда я что-то не догоняю.

По поводу Мюллера я на самом деле понял на что вы намекаете.
SQL прекрасно служит скрытию/изоляции реализации - он вообще говоря намного больше подходит как средство общения между уровнями чем SEEK() и т.д. Вот что я имел в виду. Вы запрашиваете сервис БД - она его выполняет и предоставляет результат. В случае же с VFP - вам приходится писать метод для реализации алгоритма самостоятельно. Тут очень все тонко - т.е. все тоже самое но повернутое ну скажем на 30 градусов. Согласен - это все очень относительно и сравнивать эти продукты я формально не имею право - так как знаком только с одной стороной - так что ответ за вами.

Про экономические выгоды FB и MySql - это же чистые СУБД. Среда разработки все равно платная...Ну да ладно это не так важно
А развер VFP бесплатен? и намного ли он дешевле чем C#?
А во-вторых - цена среды разработки существенно только для очень небольшой системы - обычно важны как раз лицензии на используемое ПО( сервер БД/сервер прложений/ОС/железо/сопровождение и т.д.)

VS2002 дороже VFP7 в среднем в 2 раза 500 против 1000$ - так что это не существенно для любого более менее крупного проекта

VFP в данном случае выступает лишь как инструмент и зачастую очень удобный. Выбор того или иного инструмента скорее дело вкуса разработчика.
Неверно, VFP - в данном случае - это более чем инструмент - это идеология построения ИС.

Дискуссия, мне кажется, пошла не в том направлении...
Почему?