dbf sql 

Чем формат DBF отличается от  SQL? 

В чем основные отличия формата DataBase Format от распространенных форматов баз данных - SQL?
В чем недостатки этого формата?

SQL — это не формат. Это, скорее, язык. Язык запросов к базе данных.

Формат DBF предназначен для того, чтобы приложение непосредственно работало с БД. Современные же БД представляют собой отдельный сервис, к которому могут обращаться приложения. Это позволяет, в частности, работу нескольких приложений с одной БД одновременно. К тому же DBF есть проблемы с кодировками и много с чем ещё. Да и база в виде кучи файлов — это не всегда хорошо, хотя и некоторые клиент-серверные БД хранят данные аналогичным образом. Если не ошибаюсь, транзакций у библиотек для работы с DBF тоже не предусмотрено. Много чего ещё можно сказать, вопрос в том, что именно тебе надо.


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

      А что есть DBMS SQL? О программных продуктах с таким наименованием что-то не слышал, а вообще DBMS — это просто СУБД по-русски?

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

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

Только к сожалению в нашей действительности почти никому ничего не нужно. Да и видишь, допустим используется в этой компании N-ное количество программных продуктов, которые данные хранить по иному не умеют и не будут, и что ты им скажешь? Что плохо, что данные так хранятся, надо что-то делать, а что именно-то делать? И во сколько для компании обойдётся, допустим, замена этих продуктов и импорт данных из них во что-то другое? А ещё есть такой элемент, как сотрудники, которые привыкли что всё вот так, пусть даже это неудобно и предлагать им какие-либо альтернативы себе дороже. Не всё так просто в этом мире.

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

bdf - формат файлов самой базы данных
sql - формат эскюэл запросов пользователя

dbf - dbase формат. Разработан где-то в середине 80-х, точно не скажу. Абривеатура от Data Base File. Первоначально применялся СУБД (Система управления базами данных) Dbase Достоинства и недостатки правильно написаны у katzyn. Нет нужды переписывать.
SQL (Structured Query Language) — язык структурированных запросов. Изначально разрабатывался для того, чтобы пользователи, не имеющие навыков программирования, могли сами формулировать запросы к базам данных. В первоначальном виде ANSI-I появился задолго до появления клиент-серверных СУБД (SQL-серверов) поддерживался ODBC драйверами всех СУБД, в том числе и вышеупомянутой DBase. 

Перевод базы из SQL в DBF  в 1С: 

 Делаеш выгрузку базы из SQL, создаеш новый каталог, заходиш конфигуратором, указываеш формат данных dbf, и потом загружаеш что выгрузил из SQL. Вот и все, база готова

Пример

Столкнулся с такой задачей. Надо загрузить из dbf в SQL. dbf-ка содержит ~ 900 000 зписей. Если тупо подгружать dbf-ку в TTable
и, ползя по ней циклом вставлять записи в SQL, то это жутко долго. Можно ли сделать этом разом, или порциями по 1000 записей. Чтобы ускорить процес.
Пробовал резать dbf на части, но сам процесс нарезания их из общей также саязан с циклом по исходной dbf-громадине.

Суть в следующем: Нужен компонент, позволяющий импортировать напрямую из dbf в SQL, либо возможность как-то порубить программно dbf-ку на доли не "ползая" по
ней. Ну или другое альтернативное решения?

Попробуй TBatchMove настрой алиасы и всё должно пойти.

dbf-это плоский файл БД
SQL-это язык а не БД.

Чего то я не догнал ответа от Bas
"
Попробую изложить подробнее.
Есть файл spisok.dbf определенной структуры.
Есть также MS SQL Server 2000, на котором поднята база. В этой базе есть таблица spisok, с такой же структурой как и в dbf.
Надо из spisok.dbf перегнать данные в таблицу spisok sql-ой базы. И все! Но как?
Пробовал прямо из SQL делать вставку типа insert INTO spisok (p1, p2, ...) select p1, p2, ... from "C:\spisok.dbf"
и т.п., но SQL 2000 не потдерживает обращение к DBF. В TQuery это тоже не прокатывет.

Спасибо за совет. про TBatchMove почитал, только он делает импорт данных из таблицы или выборки по запросу В ТАБЛИЦУ,
а мне надо наоборот из таблицы в выборку (из dbf в SQL)

Да всё нормально, делаешь например в SQL Explorer два алиаса один SQL, другой Standart. Берёшь один Table1 в DatabaseName указываешь алиас Standart и в свойство BatchMove-Destination указываешь Table1, и второй Table2 алиас SQL и в BatchMove-Source указываешь Table2.
Если надо в проге изменять алиасы тогда кидаешь два TDatabase и через них делаешь два алиаса.

Два TDatabase, два TTable и BatchMove сделали свое дело оперативно и правильно.
Немного помучился с кодировками, но все получилось.