Почему только Делфи?

← →
DonVik (2006-08-23 15:35) [0]

Собственно, давно хотел выяснить такой вопрос. Довольно часто задают вопрос как работать с dbf-файлами Фокса в Делфи. И по смыслу вопроса кажется, что нужно сделать что-то достаточно простое (открыть файл, показать, закрыть, удалить записи). Мне непонятно почему такие вещи делаются в Делфях. Ну красивый интерфейс, ну привычный язык - а по серьезному?. Особенно если учесть, что в VFP более 800 команд и функций, да и еще любые свои можно создавать. Кроме того, в VFP интерфес можно создать не намного менее привлекательный. Вот пример: нужно в какое-то поле записать модуль номера записи по основанию, например, 3, если поле Field2#0 (не нуль)
На Фоксе:
Use <File>
Go top
Replace all Field with MOD(RECN(),3) for Field2#0
Use

Я уже не говорю о таком "оружии" как компактные индексы с выражениями, чего нет ни в одной известной мне БД и которые не поддерживаются БДЕ.
Может быть, это происходит от незнания языка и возможностей VFP? Но это-же, скажем так, не очень серьезно. Единственный более-менее серьезный аргумент - необходим VFP на машине. Но его минимальный объем ~17 МБ. Даже Exe-шники можно делать, зарегистрировав 3 DLL (~7 МБ)
Понимаю, вопрос не в тему Делфи, а все-же, может быть выскажетсь, просветите... И не считайте меня засланцем, как обозвали на одной из веток. Мне правда хочется понять - почему ТОЛЬКО ДЕЛФИ?

← →
Курдль © (2006-08-23 15:41) [1]

А, опять некрофилы... :(

← →
Sergey13 © (2006-08-23 15:42) [2]

> [0] DonVik (23.08.06 15:35)

А кто сказал что ТОЛЬКО Делфи? Фамилию назови. Нравится лиса - ну и делай на ней.

← →
MsGuns © (2006-08-23 15:44) [3]

Ты путаешь СУБД-ориентированные среды и среды разработки приложений.
Не надо приводить в качестве аргументов такие вещи, как "быстрее" и "проще". Мне, к примеру, затруднительно придумать, каких манипуляций с БД НЕЛЬЗЯ делать в Дельфи. В то же время в твоем же фоксе проще перечислить, что МОЖНО.

← →
MsGuns © (2006-08-23 15:46) [4]

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

← →
Marser © (2006-08-23 15:56) [5]

> [4] MsGuns © (23.08.06 15:46)
> "Быстрее" и "проще" в подавляющем большинстве случаев лишь
> производные от количства знаний и опыта программиста.

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

← →
DonVik (2006-08-23 16:06) [6]

> MsGuns © (23.08.06 15:44) [3]
> Ты путаешь СУБД-ориентированные среды и среды разработки
> приложений.
> Не надо приводить в качестве аргументов такие вещи, как
> "быстрее" и "проще". Мне, к примеру, затруднительно придумать,
> каких манипуляций с БД НЕЛЬЗЯ делать в Дельфи. В то же
> время в твоем же фоксе проще перечислить, что МОЖНО.

Может я и не совсем правльно выразился. Я имел ввиду проще, быстрее для себя - много лет работал на фоксе. Но это не важно.
Я понимаю, что Делфи не СУБД. И я согласен что на Делфях можно сделать ВСЕ, что и на фоксе.
Но вот например. Представьте себе, что руководству требуется какая-то выборка из 20-30 файлов, да еще в кросс-таблицу, причем работа РАЗОВАЯ (ну ОЧЕНЬ начальству хочется!). Для Делфи нужно приконектится ко всем файлам и составить SQL-запрос. Пишется он ручками - нет визуальных построителей (если я не прав - поправте, я такие задачи для себя делаю на Фоксе). И начинается его отладка - а текст довольно длинный. Далее компиляция, выполнение, анализ на правильность (проверка, правильно ли составлен SQL-запрос). Данные в файлах не видны. А в Фоксе это все визуально - открываю все файлы, визуально устанавливаю отношения, генерю крос-таблицу, выполняю, и не выходя открываю браузеры просмотра каждого файла и выборки. Можно даже выполнить команды по тестовой проверке выбранных данных.
Я не утверждаю, что в Делфях что-то сделать нельзя, но просматривая топики в ветке БАЗЫ, создается такое впечатление, что ЛЮБУЮ задачу пытаются решить ТОЛЬКО на Делфях (кстати, другие задачи - как правило, клиентские, делаю на Делфи).
А что касается "некрофилов" - плиз, разьясните почему? Или Курдль считает, что Фокс умер? Зря. МикроСофт утверждает, что 16% экономических програм написаны на VFP (может самореклама?). И вот Вам пример - лет 5-6 назад ВСЕ программы налоговой службы Украины (я с Украины) были на Фоксе - думаю и сейчас также.
Есл Мастерам неохота мне разьяснять - плиз, скажите что не интересно, и я заткнусь, не буду Вам мешать жить...

← →
Danilka © (2006-08-23 16:11) [7]

> Но вот например. Представьте себе, что руководству требуется
> какая-то выборка из 20-30 файлов, да еще в кросс-таблицу,
> причем работа РАЗОВАЯ (ну ОЧЕНЬ начальству хочется!).

Если каким-то бесом у меня окажуцца эти самые 20-30 ДБФок, то я их выгружу в орокол либо в мсскл и дальше уже средствами средств администрирования :) состряпаю запрос(ы), выгружу в эксель, а там отформатирую.

а вообще, нафига нужны сейчас эти дбф-ки?

кистати, индекс по функции в орокле, таки, есть. это в ответ на "индексы с выражениями".

> но просматривая топики в ветке БАЗЫ, создается такое впечатление,
> что ЛЮБУЮ задачу пытаются решить ТОЛЬКО на Делфях

дык! форум-то дельфовый.

← →
Сергей М. © (2006-08-23 16:12) [8]

> руководству требуется какая-то выборка из 20-30 файлов

Это что, ТЗ ?!!!

← →
Sergey13 © (2006-08-23 16:13) [9]

> Представьте себе, что руководству требуется какая-то выборка
> из 20-30 файлов

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

← →
Marser © (2006-08-23 16:13) [10]

Моя тётя вроде ещё до сих пор совмещает работу в 1С в семейной фирме и работу на швейной фабрике, где всё ещё используют ФоксПро и переводить неому, только поддерживать...

← →
Плохиш © (2006-08-23 16:18) [11]

> Почему только Делфи?

Ну хотя бы потому, что сайт называется delphimaster.

PS. Надоели свяшенные войны :-(

> И по смыслу вопроса кажется, что нужно сделать что-то достаточно
> простое (открыть файл, показать, закрыть, удалить записи).

Ну школьники-то должны с чего-то начинать изучение работы с базами данных.

← →
DonVik (2006-08-23 16:31) [12]

Danilka!
дык! форум-то дельфовый - это понятно, я пытаюсь понять, почему не советуют как проще решить другими средствам, а не только Делфями. Может снобизм - Делфи все, остальное ничего? А насчет нафига - пока еще есть программы (старые) которые работают с dbf-ками.
Насчет индексов с выражениями в Оракле - правда, не знал. Я только выбираю данные из БД Оракла (не программирую - у меня в основном другие задачи)

← →
Sergey13 © (2006-08-23 16:34) [13]

> [12] DonVik (23.08.06 16:31)
> дык! форум-то дельфовый - это понятно, я пытаюсь понять,
> почему не советуют как проще решить другими средствам,
> а не только Делфями.

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

← →
Vlad433 © (2006-08-23 16:37) [14]

Я сам старый фоксист. НИКОГДА ничего плохого про фокс не скажу. Часто использую его для работы с локальными таблицами (dbf). Фокс и позиционируется в основном как средство работы с локальными данными.
Просто разные это продукты. Как например кефир и пиво. И цели у них разные.
Дельфи это не средство работы с локальными данными а нормальный язык и RAD "в одном флаконе", больше возможностей, есть удобные ср-ва работы с ф-ми Windows, сотни визуальных компонент, программа даже выглядит "красивее".
Построители SQL вроде есть как компоненты только нафиг они нужны, что, кто-то SQL не знает что ли ?
Составлять запрос в IBExpert (для Firebird) ничуть не сложнее чем в окне команд фокса и результат тоже видно. ADO - не знаю есть ли в фоксе, скорее всего в дельфях оно лучше. Все ИМХО.

← →
boriskb © (2006-08-23 16:39) [15]

DonVik (23.08.06 16:31) [12]
почему не советуют как проще решить другими средствам

Fox с различными приставками это круто!!
Это просто замечательно.

Но старо :)
Каждой задаче свой инструмент.

То есть городской телефонный справочник я и сейчас сделал бы на dbf и фоксе

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

Если же будут напрягать (что весьма вероятно) вот тогда и задумаешься: "А чего получше нет?"

← →
Плохиш © (2006-08-23 16:39) [16]

> Vlad433 © (23.08.06 16:37) [14]
> что, кто-то SQL не знает что ли ?

В "Базы" зайди ;-)

← →
Ega23 © (2006-08-23 16:39) [17]

> Представьте себе, что руководству требуется какая-то выборка
> из 20-30 файлов, да еще в кросс-таблицу, причем работа РАЗОВАЯ

Ну и что? Я это на сабже сделаю достаточно быстро.

← →
DonVik (2006-08-23 16:42) [18]

Плохиш!
Ну школьники-то должны с чего-то начинать изучение работы с базами данных.

Школьник, допустим, имеет представление о Делфи - и идет сюда. Вот и кажется, что других вариантов нет. Но вот что интересно - я паре студентов (кажется 2-го курса) визуально в Фоксе показал построение отношений. И они сказали, что за полчаса моих обьяснений поняли гораздо больше, чем когда им обьясняли что это такое и как это делается на Делфях. Я не хвастаюсь - просто визуальная среда сильно облегчает работу.

← →
Ega23 © (2006-08-23 16:46) [19]

> и как это делается на Делфях

Строить отношения в БД на Делфи - всё равно что вырывать больному зуб через задницу. Теоретически - можно. Практически - бессмысленная трата времени.

← →
Sergey13 © (2006-08-23 16:51) [20]

> [19] Ega23 © (23.08.06 16:46)
> Строить отношения в БД на Делфи - всё равно что вырывать
> больному зуб через задницу. Теоретически - можно. Практически
> - бессмысленная трата времени.

Я бы перфразировал слегка

Строить отношения в БД не внутри самой БД - всё равно что вырывать больному зуб через задницу. Теоретически - можно. Практически - бессмысленная трата времени.

← →
DonVik (2006-08-23 16:54) [21]

boriskb!
Каждой задаче свой инструмент - в том-то и дело. Вот тут я полностью согласен. Просто пытаюсь понять, почему этот принцип не используется. А что касается 10-ка гиг - такие задачи конечно нужно делать в Оракле или чем-то подобном. А если 20-30 файлов вместе тянут -5-7 мег?

Vlad433
В VFP начиная с 6-й версии (более ранние не имел) - ADO есть и работает нормально. Именно через них я чаще всего и вытаскиваю данные из Оракла.
И еще ты писал - "Я сам старый фоксист. НИКОГДА ничего плохого про фокс не скажу. Часто использую его для работы с локальными таблицами (dbf). Фокс и позиционируется в основном как средство работы с локальными данными.". Вот это, наверное, и есть нормальный ответ на мой недоуменниый вопрос - "каждому овощу - своя банка", как говаривала моя любимая учительница ИНЖЕНЕРНОГО ДЕЛА. Инструментарий должен подбираться под задачу. Делать ВСЕ только одним топором можно (предки церкви так строили), но небоскреб так не построишь (теоретически можно, а практитчески...).

← →
Ega23 © (2006-08-23 16:56) [22]

> Строить отношения в БД не внутри самой БД - всё равно что
> вырывать больному зуб через задницу. Теоретически - можно.
> Практически - бессмысленная трата времени.

Отнюдь. Sybase Power Designer - отличное средство для работы с физической структурой БД. Я, к примеру, уже давным-давно Enterprize Manager в MSSQL не использую.
Но этот пакет изначально под эти задачи заточен.

← →
Sergey13 © (2006-08-23 17:00) [23]

> [22] Ega23 © (23.08.06 16:56)
> Отнюдь. Sybase Power Designer - отличное средство для работы
> с физической структурой БД.

Я имел в виду, что если отношения нет БД, а есть только в юзерском интерфейсе, то дальше то что ты писАл.

← →
Ega23 © (2006-08-23 17:02) [24]

> Я имел в виду, что если отношения нет БД, а есть только
> в юзерском интерфейсе, то дальше то что ты писАл.
>

А, ну тогда да, тогда я согласен.

← →
Дураг (2006-08-23 17:08) [25]

> DonVik (23.08.06 15:35)

А почему именно DBF лучше уже акцесс или тот же FB Embeded...

← →
DonVik (2006-08-23 17:09) [26]

Sergey13, Ega23
Да я и не пытаюсь строить отношения в Делфях (по вами указанным причинам). А вот в Фоксе наоборот, предпочитаю строить отношения - мне (лично) так проще проверять правильность связок записей. А в общем, вижу что на форуме есть ДЕЙСТВИТЕЛЬНО МАСТЕРА, имеющие свое мнение, а не пинающие меня ногами только за то, что я на форуме по Делфям затронул вопрос о Фоксе.

← →
Ega23 © (2006-08-23 17:14) [27]

> мне (лично) так проще проверять правильность связок записей.

Не забывай, что Delphi - это всего лишь инструмент. Я знаю одного мужика, который бензопилой на доске расписаться может. Этой же бензопилой можно и дрова пилить, и гвозди забивать и даже использовать её в качестве груза для фарватерной сетки. Всё зависит от мозгов того, кто эту пилу в руках держит, только и всего... :о)

← →
Дураг (2006-08-23 17:17) [28]

> Я не хвастаюсь - просто визуальная среда сильно облегчает
> работу.

Тогда уж лучше акцесс. А чтобы понять книжки нужно читать, а не лекции прогуливать и кнопки на форму кидать...

DonVik (23.08.06 16:54) [21]
Просто пытаюсь понять, почему этот принцип не используется.

Ну почему же не используется?
Очень даже используется.

Это все равно что зайти в гараж с крутыми иномарками и начать их донимать: "А почему вы уголь не возите?"

Возят. Только не они :)

Сталкивался с фоксом не сильно, но приходилось сопровождать и дорабатывать.
1. Ущербный SQL язык. Не помню, уже точно, но законнектившись к IB не смог использовать массу возможностей.
2. Низкая надежность БД, при любом незапланированном отключении компьютера то индексы падают, то какой то файл, объеденяющий таблицы в базу рушится. Пришлось отсоединять таблицы.
3. Для примитивной работы с сетью, пришлось писать dll, хотя может и можно по другому.
4. Очень непривычная и неудобная среда, для людей работающих с Delphi, C, ASM. (она может и неплохая для тех кто привык)
Это первое что пришло в голову.

Когда здесь задают вопросы о работе с DBF, обычно речь идет о том, чтобы перегнать информацию из DBF в нормальную базу, а не о том, чтобы работать с самими DBF-ами.

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

Я хорошо знал FP 2.6 и мне было проще продолжить проектировать под Windows на VPF, чем переходить на Delphi и SQL. Слава богу, что я не выбрал тогда легкий путь, а выбрал то, что мне показалось более изящным и умным. То есть выбрал ООП и SQL. Хотя это потребовало изменить в голове ряд извилин.

Если сейчас мне нужно сделать локальную базу данных, то первое, что мне придет на ум - Firebird Embedded. И последнее, что мне придет на ум - DBF. Так как Firebird Embedded при желании я легко могу превратить в клиент-серверное приложение, просто поставив Firebird Server.

А с DBF-ами я буду:
1. Обречен на файл-серверную архитектуру.
2. Обречен жаться с длиной строк и всякий раз в уме подсчитывать потенциальные мегабайты завершающих пробелов в строках.
3. Обречен жаться с разрядностью чисел, зная, что каждый десятичный разряд занимает байт вместо положеннных менее полубайтов или прибегать к извратам вроде тех, к которым прибегают все разработчики, пишущие на клиппере, фоксе и т.п., ради экономии кодирующие числа и даты в байты хитрыми способами, в которых потом приходится разбираться дешифровальщикам.
Я сейчас как раз разбираюсь с одной такой базой данных. Мне в наследство оставили некие закорюки в полях C(2), которые, как я прощучил, означают вот что: если восстановить ASCII-коды из этих строк закорюк (включая символ с ASCII-кодом 0, что делать следует весьма аккуратно в ADO), то, например:
"ЛL" означает (если в шестнадцатиричном виде записать) $4CCB,
а это (в десятичном запишу, чтобы понятнее было) есть число 19659,
что, оказывается, нужно понимать, как число суток, которые следует отсчитать от 1 января 1950 года включительно (почему так - у меня не спрашивайте) и тогда мы получим дату 29.10.2003 (!!!), что и имели в виду разработчики приложения, которые писали "ЛL" в поле своей DBF-ки ради экономии места (и повышения скорости).

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

Сказано: по плодам их судите их. Плоды DBF - извраты.

И сам я прибегал к этим извратам, когда писал программы во времена FoxPro. И считал это своим профессионализмом. Так как нормальный человек не может долго терпеть формат, в котором числа вместо двоичной формы хранятся в виде символьных строк. И какой-нибудь дохлый миллиард занимает аж целых 10 байт места на диске вместо 4. Я уже не говорю о концевых пробелах строк - все базы той же 1С 7.7 состоят из гигабайтов пробелов.
И уж совсем молчу про 10 символов в названиях полей...

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

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

DBF - отличный формат, прям как карбюратор - продул и едет.
Всякие однофайловые многотабличные системы - вот это изврат, дико-растущая сущность, мало подчиняющаяся законам логики.

> Так что для меня лично DBF - это то, из чего следует информацию
> как можно скорее перегнать в какой-нибудь более удобоваримый
> вид, а потом уже думать, что с этим делать.

А для меня сущность которую можно спокойно перегнать в любой формат, не парясь о совместимости.

ЗЫ: Если у вас проблемы с Dbf - выпрямите руки на руковыпрямительном станке.

2 Другой © (23.08.06 22:55) [32]
Поле называется d_pblbaz, что (как я вычислил своим дедуктивным методом) означает "дата последней кроводачи базовая":

d - дата
p - последней (от русского posledny)
bl - кроводачи от английского (blood)
baz - базовая (от русского bazovaya)

:)))

На самом деле чуваки профи.
Проблема DBF именно в том, что если ты профи, то должен обязательно извращаться. Если дату можно в два байта впихать, зачем на нее 8 байт тратить, как это в DBF принято?
Вот и извращался народ - переводил все в бинарный вид, как мог. Все кроме строк, разумеется.
Проблема в том, как это потом все импортировать в нормальную базу.
Простыми датапампами не выходит. Так как ряд полей, которые символьные, на при импорте нужно воспринять как бинарные, а для этого в ADO нужно специально тип каждого такого поля приводить (CAST) к BYTEARRAY в SQL-запросе, иначе терминаторы конца строки (символ 0) съедят существенную информацию, следующую за нулевыми символами. А кроме ADO (OLEDB провайдер Visual Foxpro) хрен чем прочитаешь эти DBF-ы, не утеряв при этом мемо-поля и не наткнувшись на сообщения "заголовок испорчен". Может и прочитаешь, только мне такой способ неизвестен...
Вот и представьте себе, какие у меня чувства к DBF-формату.
Вся проблема этого формата в одном - там не хватало поля типа BYTEARRAY. И если бы у Microsoft были мозги, когда они FP купили, им следовало бы ввести хотя бы этот тип поля. А еще лучше - ввести бинарные числовые типы в качестве "расширения формата". Ведь ввели же фокспрошники тип MEMO - не побоялись. Вот тогда народ бы не извращался, и в будущем не было бы проблем с перекачками данных в другие форматы.

Поэтому сабж предлагаю рассмотреть в такой последовательности:
1. Есть ли какой-либо резон в DBF-формате вообще? То есть есть ли разумные аргументы в пользу того, чтобы хранить числа и даты в текстовом виде и концевые пробелы строк, создающие сотни мегабайт балласта...
2. Есть ли какие-либо задачи, которые невозможно было бы решить, не прибегая к хитроумным индексам по выражениям, использующим пользовательские функции? Может быть проще прописать такие функции в триггерах и хранить их результаты в специальных полях и потом просто индексировать по этим полям, как это и принято в SQL и если уж совсем без этого никуда...?
3. Есть ли вообще смысл в файл-серверных подходах, если клиенты все равно рано или поздно хотят подключить еще парочку пользователей к той же базе?

То есть сначала мы выносим приговор самому формату dBase. А затем уже взглянем на то, что останется под таким углом: а если VFP только и умеет, что работать с этими dBase форматами, то нафиг тогда оно может понадобиться, если мы все равно от них вынуждены отказаться, если не хотим повторять извраты, на которые шли профессионалы до нас, запихивая числа и даты в бинарные строки?

tesseract © (23.08.06 23:25) [34]
ЗЫ: Если у вас проблемы с Dbf - выпрямите руки на руковыпрямительном станке.

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

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

Что такое сущность, мало подчиняющаяся законам логики?
:)
И почему это дико-растущая?
После перегонки dbf-а в InterBase размер базы данных падает в разы, если не на порядок. За счет все тех же простых вещей: бинарное кодирование чисел и отсутствие такого идиотизма, как явное хранение концевых пробелов строк.
И вообще я работал с dBase форматом лет 10, прежде чем полностью от него отказался. Кроме хитроумных индексов по пользовательским функциям в нем вообще нет никаких плюсов по отношению ни к чему.

"holy, holy war! we are fighting..." (ц) Manowar.
ничего вы тут не понимаете. plain text -- это наше всё.

а если зипануть его, так объём уменьшится в разы, а то и на порядок.

(Для справки: для программиста "на порядок" означает "в два раза") ;-)

Почему только Делфи? Найти похожие ветки