DBF зачем юзают или какой формат выбрать (удачники, неудачники и просто дачники-2)
Преждевременно была закрыта тема
А зря. Весьма интересный и поучительный там диалог был.
Фиксин против форматов СУБД.
Миллионы типовых объектов против тысяч видов малочисленных документов.
1с-ники с графиками презентаций против неодобряемого 1с-ом "старья".
Что делать и куда бечь, когда перед тобой поставили задачу выгрузки чего-то там откуда-то туда.
Сегодня дошли руки сделать выгрузку из 7.7.
Справочник номенклатуры - 31 тыс наименований.
Выгружается весь - 30 полей каждой карточки.
Сделал через DBF - выгрузка заняла 2,5 минуты. До этого - сутки выгружалось через правила КД в XML.
Размеры файлов - 220 Мб против 345 Мб.
Снова было доказано непреложное:
если данные однотипные и структурированы, и их очень много - только DBF. Причем в текстовый файл тоже самое выгружается часа полтора. Но текстовик размером 300 МБ потом будет читаться часов 25.
Честно, поражен скоростью DBF.
Для выгрузки миллионострочных справочников - самое то.
Впрочем, если напрячься, и есть время - то и документов тоже. Правда, с документами сложнее - если их больше 5 видов, долго писать структуры для DBF - надо же на шапку, на ТЧ свои таблицы выгрузки. Да еще с поиском либо созданием элементов справочников.
Но - впечатлен. Не ожидал, что DBF ТАК обставит текстовый файл - собственно, как самолет велосипед.
Конечно, "прогрессивные" 1с-ники могут попенять на конкретную реализацию выгрузки-чтения текстовика в 1с. Но что есть, то есть. И в конце концов, на то они и "прогрессивные" в 1с, чтобы ругать все, что выходит за рамки концепций и представлений 1с.
А зря. Весьма интересный и поучительный там диалог был.
Фиксин против форматов СУБД.
Миллионы типовых объектов против тысяч видов малочисленных документов.
1с-ники с графиками презентаций против неодобряемого 1с-ом "старья".
Что делать и куда бечь, когда перед тобой поставили задачу выгрузки чего-то там откуда-то туда.
Сегодня дошли руки сделать выгрузку из 7.7.
Справочник номенклатуры - 31 тыс наименований.
Выгружается весь - 30 полей каждой карточки.
Сделал через DBF - выгрузка заняла 2,5 минуты. До этого - сутки выгружалось через правила КД в XML.
Размеры файлов - 220 Мб против 345 Мб.
Снова было доказано непреложное:
если данные однотипные и структурированы, и их очень много - только DBF. Причем в текстовый файл тоже самое выгружается часа полтора. Но текстовик размером 300 МБ потом будет читаться часов 25.
Честно, поражен скоростью DBF.
Для выгрузки миллионострочных справочников - самое то.
Впрочем, если напрячься, и есть время - то и документов тоже. Правда, с документами сложнее - если их больше 5 видов, долго писать структуры для DBF - надо же на шапку, на ТЧ свои таблицы выгрузки. Да еще с поиском либо созданием элементов справочников.
Но - впечатлен. Не ожидал, что DBF ТАК обставит текстовый файл - собственно, как самолет велосипед.
Конечно, "прогрессивные" 1с-ники могут попенять на конкретную реализацию выгрузки-чтения текстовика в 1с. Но что есть, то есть. И в конце концов, на то они и "прогрессивные" в 1с, чтобы ругать все, что выходит за рамки концепций и представлений 1с.
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)Попробуйте выгрузить из 7.7 и из 8-ки в xml-файлы. Понимаю, что для чистоты эксперимента трудно найти похожие конфигурации, но можно перенести из 7-ки в 8-ку, например, номенклатуру. И чем больше по объему будет справочник, тем лучше. Результаты, думаю удивят. У 7.7 проблемы с записью xml - очччень медленно работает.
Например, переход с ЗиК на ЗУП обернулся кошмаром. Типовую выгрузку через xml пришлось разбивать на части, т.к. не хватало памяти (4 ГБ оперативки) и 7-ка падала. Выгрузка из ЗиК в итоге шла двое суток, загрузка в ЗУП - 1.5 часа.
А что касается выбора между *.dbf или *.xml, то к этому стоит подходит как к выбору конкретного инструмента в конкретной задаче. Если мне нужно срочно и единожды перенести некий справочник (документ), то конечно же, сделаю через dbf. А вот настроить постоянный обмен сложной структуры, то уж увольте, через xml.
Например, переход с ЗиК на ЗУП обернулся кошмаром. Типовую выгрузку через xml пришлось разбивать на части, т.к. не хватало памяти (4 ГБ оперативки) и 7-ка падала. Выгрузка из ЗиК в итоге шла двое суток, загрузка в ЗУП - 1.5 часа.
А что касается выбора между *.dbf или *.xml, то к этому стоит подходит как к выбору конкретного инструмента в конкретной задаче. Если мне нужно срочно и единожды перенести некий справочник (документ), то конечно же, сделаю через dbf. А вот настроить постоянный обмен сложной структуры, то уж увольте, через xml.
(29) Relfirby,
зачем мне "пробовать", я и так перегружаю Номенклатуру из 7 в 8-ку. И конкурент dbf - разве что только SQL-формат. Но там скорость пожиже, и драйвер нужен.
Но структура файла проще.
Попробуйте выгрузить из 7.7 и из 8-ки в xml-файлы
зачем мне "пробовать", я и так перегружаю Номенклатуру из 7 в 8-ку. И конкурент dbf - разве что только SQL-формат. Но там скорость пожиже, и драйвер нужен.
Но структура файла проще.
(29) Relfirby,
правильно, потому что 1с настольок непредсказуема, что ожидаешь одни данные, а там - нечто другое уже. И DBF такие вольности не позволяет.
Но никто не правит выгруженный xml. Потому как нет средств для этого.
А вот dbf подправить - пожалуйста, хоть оптом, хоть в розницу.
А вот настроить постоянный обмен сложной структуры, то уж увольте, через xml.
правильно, потому что 1с настольок непредсказуема, что ожидаешь одни данные, а там - нечто другое уже. И DBF такие вольности не позволяет.
Но никто не правит выгруженный xml. Потому как нет средств для этого.
А вот dbf подправить - пожалуйста, хоть оптом, хоть в розницу.
(0)(1)
"2,5 минуты"(с) для такого объема - это очень много. Думаю, основное время уходит на чтение исходного справочника. Точнее, время уходит на вытаскивание информации из полей БД в "1С-структуры представления" информации в оперативной памяти. И обратные действия для результирующего DBF-а 1С делает очень медленно. А сама запись в DBF на уровне его движка, для такого объем, займет несколько секунд. ;-)
"2,5 минуты"(с) для такого объема - это очень много. Думаю, основное время уходит на чтение исходного справочника. Точнее, время уходит на вытаскивание информации из полей БД в "1С-структуры представления" информации в оперативной памяти. И обратные действия для результирующего DBF-а 1С делает очень медленно. А сама запись в DBF на уровне его движка, для такого объем, займет несколько секунд. ;-)
(2) hogik,
какое много! если сравнивать с записью в текстовики (txt, xml, csv, тут же и mxl) - это почти что секунды!
Я когда первый раз выгружал - чай приготовил (по аналогии с прошлыми выгрузками), так чай так и остыл из-за нехватки на него времени ))
И что еще немаловажно - открытый файл DBF вполне читабельный и прокручиваемый, в отличие от того же XML - который после 10 МБ надо по полминуты ждать обновления страницы, да еще далеко не всякий вьювер и прочитает такой объем...
какое много! если сравнивать с записью в текстовики (txt, xml, csv, тут же и mxl) - это почти что секунды!
Я когда первый раз выгружал - чай приготовил (по аналогии с прошлыми выгрузками), так чай так и остыл из-за нехватки на него времени ))
И что еще немаловажно - открытый файл DBF вполне читабельный и прокручиваемый, в отличие от того же XML - который после 10 МБ надо по полминуты ждать обновления страницы, да еще далеко не всякий вьювер и прочитает такой объем...
Да, здоровенные xml и txt файлы читаются и открываются ну очень долго и тяжело.
Но зато - формат открытый, добавляй что хочешь и сколько хочешь, а в DBF даже поле новое программно добавить это как-то непросто. Так что - выигрыш в скорости, проигрыш в гибкости.
Но зато - формат открытый, добавляй что хочешь и сколько хочешь, а в DBF даже поле новое программно добавить это как-то непросто. Так что - выигрыш в скорости, проигрыш в гибкости.
(9) Alex_Japanese_Student,
а я свои xml-ки вообще не могу править в текстовом режиме - либо памяти не хватает, либо все так долго, что не хватает терпения. Притом что поиск в тексте XML-файла - очень мазохисткое занятие...
FAR быстрее, но кардинально проблемы не решает.
правлю в текстовых обычно (
а я свои xml-ки вообще не могу править в текстовом режиме - либо памяти не хватает, либо все так долго, что не хватает терпения. Притом что поиск в тексте XML-файла - очень мазохисткое занятие...
FAR быстрее, но кардинально проблемы не решает.
(14) bzmax,
с того, что редактировать xml можно и вобычном текстовом редакторе (и даже более того - схему узлов можно просматривать в браузере с поддержкой спецификации xml), а вот заточенность и специфики как файла данных (причем огромного файла данных) - нет.
с того, что редактировать xml можно и вобычном текстовом редакторе (и даже более того - схему узлов можно просматривать в браузере с поддержкой спецификации xml), а вот заточенность и специфики как файла данных (причем огромного файла данных) - нет.
(15) AlexO,
Давайте все таки вещи называть своими именами.
XML как был текстовым, так текстовым и остался(!)
Специфики никакой. Теги и текст. даже двоичные данные (если нужно передать) кодируются алгоритмом base64 в текстовую строку.
Единственное что вас беспокоит, как я понял - это ТОЛЬКО размер файла.
Так вот вы возьмите XML Notepad и попробуйте поработать. Вероятней всего он и будет долго открывать.
Но я в данном случае рассматривал не скорость работы. А опровергал ваше утверждение что не существует "нормально" XML редактора.
Есть такой редактор. И структура XML файла в нем просматривается очень хорошо и удобно.
Давайте все таки вещи называть своими именами.
XML как был текстовым, так текстовым и остался(!)
Специфики никакой. Теги и текст. даже двоичные данные (если нужно передать) кодируются алгоритмом base64 в текстовую строку.
Единственное что вас беспокоит, как я понял - это ТОЛЬКО размер файла.
Так вот вы возьмите XML Notepad и попробуйте поработать. Вероятней всего он и будет долго открывать.
Но я в данном случае рассматривал не скорость работы. А опровергал ваше утверждение что не существует "нормально" XML редактора.
Есть такой редактор. И структура XML файла в нем просматривается очень хорошо и удобно.
Прикрепленные файлы:
(17) bzmax,
во-первых, ваш редактор дает править то, что справа?
во-вторых, и самое главное: вот вы нашли ошибку в выгрузке. Как вы будете её локализовать и исправлять в xml-файле? как отличите сам объект от сохраненной ссылки на него? поиском вручную?
во-первых, ваш редактор дает править то, что справа?
во-вторых, и самое главное: вот вы нашли ошибку в выгрузке. Как вы будете её локализовать и исправлять в xml-файле? как отличите сам объект от сохраненной ссылки на него? поиском вручную?
(19) AlexO,
И то что слева то же дает править.
Посмотрел и поиск и замена есть :) (просто этими функциями не пользовался никогда).
Как правило использовал этот редактор для разработки структуры xml.
И вместо того что бы разводить 30 минут демагогию. Уже давно скачал бы и попробовал.
И то что слева то же дает править.
Посмотрел и поиск и замена есть :) (просто этими функциями не пользовался никогда).
Как правило использовал этот редактор для разработки структуры xml.
И вместо того что бы разводить 30 минут демагогию. Уже давно скачал бы и попробовал.
(14) bzmax,
т.е. вы никогда не интересовались, что такое вообще БД, и реляционные таблицы БД в частности? ))
Покажите, где в вашем редакторе поиск и сортировка по записям? Вероятней, что нет даже и по узлам, хотя это отнюдь не записи БД.
т.е. вы никогда не интересовались, что такое вообще БД, и реляционные таблицы БД в частности? ))
Покажите, где в вашем редакторе поиск и сортировка по записям? Вероятней, что нет даже и по узлам, хотя это отнюдь не записи БД.
(20) AlexO,
MS SQL или IBM DB - великолепные СУБД которые имеют инструментарий по работе с XML - файлами как с СУБД. Даже запросы можно формировать.
Да и обычный парсер WINDOWS-а тот который использует 1С для формирования и чтения XML файлов может использовать специализированный язык запросов для XML.
MS SQL или IBM DB - великолепные СУБД которые имеют инструментарий по работе с XML - файлами как с СУБД. Даже запросы можно формировать.
Да и обычный парсер WINDOWS-а тот который использует 1С для формирования и чтения XML файлов может использовать специализированный язык запросов для XML.
(21) bzmax,
вы сами-то пользовались им? я - нет, да и, как вы сами сказали "великолепные СУБД" имеют великолепные и быстродействующие средства обмена безо всяких XML, если уж мне взбредет в голову привлекать для этого сервера с MS SQL или IBM DB :))
и где средство редактирования у "обычного парсера Виндовса"? ))
СУБД которые имеют инструментарий по работе с XML
вы сами-то пользовались им? я - нет, да и, как вы сами сказали "великолепные СУБД" имеют великолепные и быстродействующие средства обмена безо всяких XML, если уж мне взбредет в голову привлекать для этого сервера с MS SQL или IBM DB :))
Да и обычный парсер WINDOWS-а
и где средство редактирования у "обычного парсера Виндовса"? ))
dbf это древний формат еще со времен ДОСа, в те времена не было многоядерных процов, оперативка смешная, а диски были тоже не огромные, поэтому понятное дело что оптимизировали его по самое нихачу, как и все тогда.
а хмл уже современный формат, более удобо читаемый
как уже сказано предыдущим
а хмл уже современный формат, более удобо читаемый
как уже сказано предыдущим
выигрыш в скорости, проигрыш в гибкости
(6) ИльяЕвгеньевич,
"древний" DBF на современном компе, на многоядерном проце, на несмешной оперативке затыкает "современный" текстовый XML - даже не знаю, с чем сравнить... пуля и пешеход.
dbf это древний формат еще со времен ДОСа, в те времена не было многоядерных процов, оперативка смешная
"древний" DBF на современном компе, на многоядерном проце, на несмешной оперативке затыкает "современный" текстовый XML - даже не знаю, с чем сравнить... пуля и пешеход.
(0)(4)
Я обратил Ваше внимание на скорость движка DBF-а и скорость 1С, использующей этот движок. ;-) Приведу только числа.
Читается таблица 2'500'000 записей, размером около 1 гигабайта. Используется индекс с размером ключа 20-40 байт. Режим - локальный. Приложение ничего не делает - просто читает все записи подряд.
Чтение в среде 1С 7.7:
1) Запуск после перезагрузки системы - 150 сек.
2) Все повторные запуски - 120 сек.
Чтение в "среде" С/С++:
1) Запуск после перезагрузки системы - 30 сек.
2) Все повторные запуски - 3 сек.
Т.е., примерно, 120 секунд трясутся байты и объекты в кишках самой 1С-а. :-)
Замеры проводились на клиент-серверном движке на базе СУБД Advantage 8.1.
Она позволяет работать с БД одновременно навигационным способом и запросами.
Пользуясь такой возможностью, выполнил запросом функцию SUM для одного поля тестовой таблицы. Получил время - 1сек.
Напрашивается простой вывод. ;-)
Использование запросов, и "запросных" СУБД в 1С-продуктах - это ускорения работы самих кишок 1С-а и мнимое упрощение процесса кодирование для программиста. А т.к. с иерархическими структурами (что и требуется в НАШИХ задачах) логичней и эффективнее работать навигационными методами приходится "изобретать" многоуровневые системы - переходники к "запросным" СУБД. Это, я к вопросу "выигрыш в скорости, проигрыш в гибкости"(5). Это когда гибкость инструмента предназначенного для ПРОСТЫХ задач оборачивается сложностью, дороговизной и низкой скоростью в РЕАЛЬНЫХ задачах.
А формат XML (как и SQL) создан для простых и конкретных задач. Т.е. "гибкость" для облегчения труда "программиста" (точнее, - кодировщика) в ущерб ВСЕГО остального...
Я обратил Ваше внимание на скорость движка DBF-а и скорость 1С, использующей этот движок. ;-) Приведу только числа.
Читается таблица 2'500'000 записей, размером около 1 гигабайта. Используется индекс с размером ключа 20-40 байт. Режим - локальный. Приложение ничего не делает - просто читает все записи подряд.
Чтение в среде 1С 7.7:
1) Запуск после перезагрузки системы - 150 сек.
2) Все повторные запуски - 120 сек.
Чтение в "среде" С/С++:
1) Запуск после перезагрузки системы - 30 сек.
2) Все повторные запуски - 3 сек.
Т.е., примерно, 120 секунд трясутся байты и объекты в кишках самой 1С-а. :-)
Замеры проводились на клиент-серверном движке на базе СУБД Advantage 8.1.
Она позволяет работать с БД одновременно навигационным способом и запросами.
Пользуясь такой возможностью, выполнил запросом функцию SUM для одного поля тестовой таблицы. Получил время - 1сек.
Напрашивается простой вывод. ;-)
Использование запросов, и "запросных" СУБД в 1С-продуктах - это ускорения работы самих кишок 1С-а и мнимое упрощение процесса кодирование для программиста. А т.к. с иерархическими структурами (что и требуется в НАШИХ задачах) логичней и эффективнее работать навигационными методами приходится "изобретать" многоуровневые системы - переходники к "запросным" СУБД. Это, я к вопросу "выигрыш в скорости, проигрыш в гибкости"(5). Это когда гибкость инструмента предназначенного для ПРОСТЫХ задач оборачивается сложностью, дороговизной и низкой скоростью в РЕАЛЬНЫХ задачах.
А формат XML (как и SQL) создан для простых и конкретных задач. Т.е. "гибкость" для облегчения труда "программиста" (точнее, - кодировщика) в ущерб ВСЕГО остального...
(26)
Именно это и написал. ;-)
В любой системе для "обмена" информации должно быть два формата. Один для "взаимосвязи" с другими системами, а второй для передачи внутри системы (продуктов одной линейки, одного изготовителя). Первому формату - универсальность для взаимодействия "разнородных" систем, второму - скорость и надежность.
При этом скорость разработки правил обмена (удобство "программирования"-кодирования) находятся на последнем месте в оценке-выборе формата обмена информацией.
Разработчики 1С-продуктов придерживаются диаметрально противоположного взгляда в задачах обмена информации. И во многих других задачах - аналогично. Что позволяет им успешно продавать свои продукты ориентированные на низкий уровень "само-сознания" покупателя. ;-) Т.е. продавать "системки" для быстрого изготовления "портянок" при помощи низкоквалифицированных "программистов" в угоду "хотелок" заказчика, который находится на "бумажном" уровне развития информационных технологий. Увы... :-(
P.S. Задачи обмена информации в рамках одной системы - не существует. Т.е. выгрузка-загрузка внутри, например, "1С 8.х" говорить об наличии огромных ошибок в проектировании самой системы.
Именно это и написал. ;-)
В любой системе для "обмена" информации должно быть два формата. Один для "взаимосвязи" с другими системами, а второй для передачи внутри системы (продуктов одной линейки, одного изготовителя). Первому формату - универсальность для взаимодействия "разнородных" систем, второму - скорость и надежность.
При этом скорость разработки правил обмена (удобство "программирования"-кодирования) находятся на последнем месте в оценке-выборе формата обмена информацией.
Разработчики 1С-продуктов придерживаются диаметрально противоположного взгляда в задачах обмена информации. И во многих других задачах - аналогично. Что позволяет им успешно продавать свои продукты ориентированные на низкий уровень "само-сознания" покупателя. ;-) Т.е. продавать "системки" для быстрого изготовления "портянок" при помощи низкоквалифицированных "программистов" в угоду "хотелок" заказчика, который находится на "бумажном" уровне развития информационных технологий. Увы... :-(
P.S. Задачи обмена информации в рамках одной системы - не существует. Т.е. выгрузка-загрузка внутри, например, "1С 8.х" говорить об наличии огромных ошибок в проектировании самой системы.
(27) hogik,
полностью соглачен.
Даже идентичные конфы со временем начинают отличаться - GUID типовых объектов, содержащимися данными, порядком объектов и т.д. - вплоть до глюков платформы, когда неизменные объекты вдруг начинают показываться как "измененные" в сравнении.
Самый лучший способ обмена - все так же, по старинке, принудительная запись в формализованные по типам данных поля.
Т.е. прозрачный обмен - подобно dbf.
Все остальное - непредсказуемые последствия и неправильные записи.
Т.е. выгрузка-загрузка внутри, например, "1С 8.х" говорить об наличии огромных ошибок в проектировании самой системы.
полностью соглачен.
Даже идентичные конфы со временем начинают отличаться - GUID типовых объектов, содержащимися данными, порядком объектов и т.д. - вплоть до глюков платформы, когда неизменные объекты вдруг начинают показываться как "измененные" в сравнении.
Самый лучший способ обмена - все так же, по старинке, принудительная запись в формализованные по типам данных поля.
Т.е. прозрачный обмен - подобно dbf.
Все остальное - непредсказуемые последствия и неправильные записи.
Для всего свой формат, когда речь идет об обмене объектов со сложной и не однородной структурой, то без xml не обойтись, да и при том затраты на разработку обмена в формате xml уменьшаются если пользоваться конфой Конвертация данных
(33) KorichevSV,
она может некорректно перенести, и её результаты крайне сложно контролировать.
Если у вас задвоятся десятки справочников - вы их как отлавливать будете? а при переносе через Кд может быть не только задвоние самих элементов, но и задвоение и кодов, и других уникальных для конкретного справочника полей, о чем КД вам не сообщит, конечно же.
если пользоваться конфой Конвертация данных
она может некорректно перенести, и её результаты крайне сложно контролировать.
Если у вас задвоятся десятки справочников - вы их как отлавливать будете? а при переносе через Кд может быть не только задвоние самих элементов, но и задвоение и кодов, и других уникальных для конкретного справочника полей, о чем КД вам не сообщит, конечно же.
(33)(34)
"затраты на разработку обмена в формате xml уменьшаются "(с)
Любое снижение затрат на разработку увеличивает затраты на эксплуатацию. ;-)
Разработка делается один раз, а эксплуатация - ежедневно.
При использовании XML для сложных структур обмена информацией требуется тщательная и высококвалифицированная проработка иерархической "схемы базы данных". Как показывает практика далеко не многие специалисты на это способны. Появление реляционной модели позволила снизить планку квалификации разработчика. И, тем самым, увеличить количество "специалистов" и скорость (стоимость) разработки информационных систем.
P.S. Вот пример низкой квалификации и, относительно, сложной структуры:
Складывается такое впечатление, что у разработчиков этой схемы XML - в школе не преподавали основы информатики. :-) Думаю, в реляционной модели (читайте - DBF) у них бы получилось лучше. :-(
"затраты на разработку обмена в формате xml уменьшаются "(с)
Любое снижение затрат на разработку увеличивает затраты на эксплуатацию. ;-)
Разработка делается один раз, а эксплуатация - ежедневно.
При использовании XML для сложных структур обмена информацией требуется тщательная и высококвалифицированная проработка иерархической "схемы базы данных". Как показывает практика далеко не многие специалисты на это способны. Появление реляционной модели позволила снизить планку квалификации разработчика. И, тем самым, увеличить количество "специалистов" и скорость (стоимость) разработки информационных систем.
P.S. Вот пример низкой квалификации и, относительно, сложной структуры:
Складывается такое впечатление, что у разработчиков этой схемы XML - в школе не преподавали основы информатики. :-) Думаю, в реляционной модели (читайте - DBF) у них бы получилось лучше. :-(
(39)
Основные подходы:
1) Иерархический.
2) Сетевой.
3) Реляционный.
4) Объектный.
Всё остальное - удобство программиста. Включая конкретизацию (выражение, описание) структур данных в том или ином формате с использованием тех или иных средств программирования.
КД, XML, DBF, CSV, TXT и т.д. - очередная подмена содержания "внешней" формой...
Основные подходы:
1) Иерархический.
2) Сетевой.
3) Реляционный.
4) Объектный.
Всё остальное - удобство программиста. Включая конкретизацию (выражение, описание) структур данных в том или ином формате с использованием тех или иных средств программирования.
КД, XML, DBF, CSV, TXT и т.д. - очередная подмена содержания "внешней" формой...
(40) hogik,
Давайте определим предмет обсуждения.
1) если мы обсуждаем типы моделей данных, то разговор ни о чем, каждый имеет свои + и -. Как уже было сказано выше реляционный лучше для работы с большими объемами однотипных данных. Иерархические при работе с разнородными данными и неоднородной структурой.
2) если по п.1 у нас нет разногласий, тогда можем перейти к практическим вопросам. Как было указано, реляционный подход хорош при переносе больших объемов "ДБФ это если перекинуть 1-2 больших таблицы".
При переносе сложных структур в использовании удобнее иерархический подход "при десятках таблиц и объектов обеспечить ссылочную целостность в выгружаемых данных задача нетривиальная."
Полностью согласен с
(29) Relfirby,
"А что касается выбора между *.dbf или *.xml, то к этому стоит подходит как к выбору конкретного инструмента в конкретной задаче. Если мне нужно срочно и единожды перенести некий справочник (документ), то конечно же, сделаю через dbf. А вот настроить постоянный обмен сложной структуры, то уж увольте, через xml."
Мне на практике чаще приходится работать со сложными и регулярными обменами. Поэтому поддерживаю развитие фирмой 1С соответствующих инструментов.
Давайте определим предмет обсуждения.
1) если мы обсуждаем типы моделей данных, то разговор ни о чем, каждый имеет свои + и -. Как уже было сказано выше реляционный лучше для работы с большими объемами однотипных данных. Иерархические при работе с разнородными данными и неоднородной структурой.
2) если по п.1 у нас нет разногласий, тогда можем перейти к практическим вопросам. Как было указано, реляционный подход хорош при переносе больших объемов "ДБФ это если перекинуть 1-2 больших таблицы".
При переносе сложных структур в использовании удобнее иерархический подход "при десятках таблиц и объектов обеспечить ссылочную целостность в выгружаемых данных задача нетривиальная."
Полностью согласен с
(29) Relfirby,
"А что касается выбора между *.dbf или *.xml, то к этому стоит подходит как к выбору конкретного инструмента в конкретной задаче. Если мне нужно срочно и единожды перенести некий справочник (документ), то конечно же, сделаю через dbf. А вот настроить постоянный обмен сложной структуры, то уж увольте, через xml."
Мне на практике чаще приходится работать со сложными и регулярными обменами. Поэтому поддерживаю развитие фирмой 1С соответствующих инструментов.
(41)
Константин (GreyJoJo).
Действительно "разговор ни о чем"(с).
Вы пытаетесь сложить килограммы с метрами. ;-)
1) "реляционный хорош при переносе больших объемов"(с)
"При переносе сложных структур в использовании удобнее иерархический подход"(с)
Т.е. сравниваем объем и сложность? :-)
2) "при десятках таблиц и объектов обеспечить ссылочную целостность в выгружаемых данных задача нетривиальная"(с)
Т.е. реляционная модель плохо обеспечивает ссылочную целостность? Используя продукты 1С Вы преобразовали иерархическую модель реальной жизни (как её видят разработчики 1С-а) в реляционную модель. Обеспечили ссылочную целостность. Ну и выгружайте информацию без обратного преобразования.
3) "Мне на практике чаще приходится работать со сложными и регулярными обменами."(с)
Я задавал вопрос-призыв в исходной теме.
Задам и в этой теме:
"Если "Требуется выгрузить расходные накладные за период со всеми элементами справочников ,.."(с), то надо задуматься не о "формате" передачи данных, а о причинах возникновения такой "постановки задачи" в 1С-продуктах. И устранять причину, а не следствие..."
4) "Поэтому поддерживаю развитие фирмой 1С соответствующих инструментов."(с)
А я не поддерживаю. ;-) Т.к. эти "инструменты" называются - лоскутная АвтоМехАнизация. Начиная от архитектуры платформы и кончая многочисленными конфигурациями, каждая из которых имеет свою собственную схему базы данных. И как следствие этого зверинца-бардака появления продуктов типа "КД" реализованного (в части формата передачи) в угоду моде и огромного количества узких "специалистов" в области знаний под названием "1С-продукт"...
Константин (GreyJoJo).
Действительно "разговор ни о чем"(с).
Вы пытаетесь сложить килограммы с метрами. ;-)
1) "реляционный хорош при переносе больших объемов"(с)
"При переносе сложных структур в использовании удобнее иерархический подход"(с)
Т.е. сравниваем объем и сложность? :-)
2) "при десятках таблиц и объектов обеспечить ссылочную целостность в выгружаемых данных задача нетривиальная"(с)
Т.е. реляционная модель плохо обеспечивает ссылочную целостность? Используя продукты 1С Вы преобразовали иерархическую модель реальной жизни (как её видят разработчики 1С-а) в реляционную модель. Обеспечили ссылочную целостность. Ну и выгружайте информацию без обратного преобразования.
3) "Мне на практике чаще приходится работать со сложными и регулярными обменами."(с)
Я задавал вопрос-призыв в исходной теме.
Задам и в этой теме:
"Если "Требуется выгрузить расходные накладные за период со всеми элементами справочников ,.."(с), то надо задуматься не о "формате" передачи данных, а о причинах возникновения такой "постановки задачи" в 1С-продуктах. И устранять причину, а не следствие..."
4) "Поэтому поддерживаю развитие фирмой 1С соответствующих инструментов."(с)
А я не поддерживаю. ;-) Т.к. эти "инструменты" называются - лоскутная АвтоМехАнизация. Начиная от архитектуры платформы и кончая многочисленными конфигурациями, каждая из которых имеет свою собственную схему базы данных. И как следствие этого зверинца-бардака появления продуктов типа "КД" реализованного (в части формата передачи) в угоду моде и огромного количества узких "специалистов" в области знаний под названием "1С-продукт"...
(43) hogik,
Я не понимаю что вы хотите доказать. Свою позицию я изложил.
"А я не поддерживаю. ;-) Т.к. эти "инструменты" называются - лоскутная АвтоМехАнизация. Начиная от архитектуры платформы и кончая многочисленными конфигурациями, каждая из которых имеет свою собственную схему базы данных. И как следствие этого зверинца-бардака появления продуктов типа "КД" реализованного (в части формата передачи) в угоду моде и огромного количества узких "специалистов" в области знаний под названием "1С-продукт"..."
Ну что же если у вас есть достойные предложение тогда надо идти в отдел разработки 1С-озолотят и с руками оторвут. Или героически писать правильные решения и платформы :)
Удачи в столь нелегком труде!
За сим откланиваюсь...
Я не понимаю что вы хотите доказать. Свою позицию я изложил.
"А я не поддерживаю. ;-) Т.к. эти "инструменты" называются - лоскутная АвтоМехАнизация. Начиная от архитектуры платформы и кончая многочисленными конфигурациями, каждая из которых имеет свою собственную схему базы данных. И как следствие этого зверинца-бардака появления продуктов типа "КД" реализованного (в части формата передачи) в угоду моде и огромного количества узких "специалистов" в области знаний под названием "1С-продукт"..."
Ну что же если у вас есть достойные предложение тогда надо идти в отдел разработки 1С-озолотят и с руками оторвут. Или героически писать правильные решения и платформы :)
Удачи в столь нелегком труде!
За сим откланиваюсь...
(44)
Константин (GreyJoJo).
Да, уж. Лучше друг-другу откланяться. А то и эту тему форума закроют. ;-)
Пустой у нас с Вами разговор получается. Вы излагаете свою позицию. А я не излагаю свою позицию, а пытаюсь Вам нечто доказывать... :-)
Константин (GreyJoJo).
Да, уж. Лучше друг-другу откланяться. А то и эту тему форума закроют. ;-)
Пустой у нас с Вами разговор получается. Вы излагаете свою позицию. А я не излагаю свою позицию, а пытаюсь Вам нечто доказывать... :-)
(46)
Константин (GreyJoJo).
Это называется - слово за слово ... по столу. ;-)
Вы меня упрекнули в том, что я Вам нечто доказываю.
И признались, что не понимаете ЧТО я Вам доказываю.
Я сообщил Вам, что НИЧЕГО не доказываю, а излагаю (как и Вы) свою точку зрения.
Заметьте, без рекомендаций Вам - где и как Вам работать... :-)
Константин (GreyJoJo).
Это называется - слово за слово ... по столу. ;-)
Вы меня упрекнули в том, что я Вам нечто доказываю.
И признались, что не понимаете ЧТО я Вам доказываю.
Я сообщил Вам, что НИЧЕГО не доказываю, а излагаю (как и Вы) свою точку зрения.
Заметьте, без рекомендаций Вам - где и как Вам работать... :-)
(44) GreyJoJo,
да никого они не озолотят - что втемяшили, то и пиарят. Причем из крайности в крайность бросает, а пользователи - крайние по разгребанию и приведению этого бардака в порядок.
в отдел разработки 1С-озолотят и с руками оторвут
да никого они не озолотят - что втемяшили, то и пиарят. Причем из крайности в крайность бросает, а пользователи - крайние по разгребанию и приведению этого бардака в порядок.
(43) hogik,
абсолютно согласен.
КД развивается также, как и вся 1С - кто-то где-то что-то напридумал, другой - придумал, как это использовать, третий - поднаписал то, что не укладывалось в схему второго...
А в результате - неустойчивая и крайне громоздкая и неповоротливая система переноса, и это - не считая вопроса, уже здесь рассмотренного, что нет средств управления XML-файлом данных.
И как следствие этого зверинца-бардака появления продуктов типа "КД" реализованного (в части формата передачи) в угоду моде и огромного количества узких "специалистов" в области знаний под названием "1С-продукт"...
абсолютно согласен.
КД развивается также, как и вся 1С - кто-то где-то что-то напридумал, другой - придумал, как это использовать, третий - поднаписал то, что не укладывалось в схему второго...
А в результате - неустойчивая и крайне громоздкая и неповоротливая система переноса, и это - не считая вопроса, уже здесь рассмотренного, что нет средств управления XML-файлом данных.
(39) GreyJoJo,
из этого я делаю вывод - что вы не делали переносов через DBF-TXT-CSV, а только краем уха слышали. Иначе - ни за что бы не объединили такие совсем разные переносы в фразе че-то там "самописные переносы".
Это у 1С, быстрей, на коленке переносы сделаны.
А тут три совершенно разных подхода к переносу - и по скорости, и по удобству, и по надежности.
2) с помощью самописных обработок через DBF/CSV/TXT и.т.д.
из этого я делаю вывод - что вы не делали переносов через DBF-TXT-CSV, а только краем уха слышали. Иначе - ни за что бы не объединили такие совсем разные переносы в фразе че-то там "самописные переносы".
Это у 1С, быстрей, на коленке переносы сделаны.
А тут три совершенно разных подхода к переносу - и по скорости, и по удобству, и по надежности.
ДБФ это если перекинуть 1-2 больших таблицы. Все остальное от лукавого.
при десятках таблиц и объектов обеспечить ссылочную целостность в выгружаемых данных задача нетривиальная. КД это все берет на себя.
А если надо внести изменения в какой нить 100 лет назад не тобой написанный перенос через ДБФ - можно сразу накрываться простыней и ползти на кладбище. В такие моменты понимаешь прелести КД.
ЗЫ: Еще ДБФ хорош любителям поперебирать ручками таблицы (а-ля 7.7) выбратьстроки() получитьстроку() - удовольствие (сомнительное) получает махровый прогер, а оплачивает часы разработки предприятие.
при десятках таблиц и объектов обеспечить ссылочную целостность в выгружаемых данных задача нетривиальная. КД это все берет на себя.
А если надо внести изменения в какой нить 100 лет назад не тобой написанный перенос через ДБФ - можно сразу накрываться простыней и ползти на кладбище. В такие моменты понимаешь прелести КД.
ЗЫ: Еще ДБФ хорош любителям поперебирать ручками таблицы (а-ля 7.7) выбратьстроки() получитьстроку() - удовольствие (сомнительное) получает махровый прогер, а оплачивает часы разработки предприятие.
(37) GreyJoJo,
Прекрасно перекидываются справочники, документы и прочее. Главное - все видно, ЧТО выгружаешь, и ЧТО загружаешь.
да, обеспечивает. Но именно это и выходит боком - что там перенеслось, как - может быть вообще невообразимая мешанина.
Если интересно - я тут тему поднял про частный случай, где КД вообще лажу выдает.
Интересно, где?
А вот там, когда перегружаешь в базу, где те же самые объекты (для пользователя те же самые), которые в источнике, были введены вручную в приемник (с другими ИД).
Все. Накрывается медным тазом все - и КД, и ЗагрузкаВыгрузкаXML (ПереносМеждуИдентичнымиКонфигурациями).
Ничего подобного. С нуля делать - да, нужно четкую структуру разрабатывать, не совсем просто. А изменения вносить - спросите у vkr, сколько десятков он переносов сделал на основе одной своей разработки.
"прелести" могут быть полностью нивелированы её недостатками. Зависит от того, с чем столкнетесь.
а ничего, что серьезная перегрузка через XML чисто технически (выгрузка данных - загрузка данных) равна по времени разработке переноса на DBF+сам перенос. А ведь надо еще сделать и отладить правила....
Почитайте первый мой пост в этой теме - выгрузка из 7.7 через КД составила СУТКИ!!! А у меня ведь далекко не самый большой справочник был - всего-то 30тыс записей в одной базе, 25 - в другой... Загружать эту фигню полученную я уже не стал - исходя из десятков переносов, сделанных на КД, я прекрасно знаю, сколько раз мне еще придется туда-сюда перегружать эти XML, править правила в КД, опять перегружать, чтобы все встало на место.
Поэтому потратил полтора рабочих дня на разработку переноса на DBF, и за считанные СЕКУНДЫ!!! перенес все, что надо. Да, тоже не сразу. Но, извините, я в течении следующих суток могу поправить все, что надо, а не ждать, пока за это время всего лишь одна выгрузка XML пройдет.
Так что против фактов не попрешь, как бы не хотелось кому-то все под общую гребенку гнать и агитировать за любимую игрушку, даже не сталкиваясь с вышеперечисленными проблемами.
а "выбратьстроки() получитьстроку()" - это очень хорошо, что у тебя все под контролем. А не "я вам все сделал - давайте деньги, и ловите потом меня в поле, какую я вам там в новой базе свалку устроил!"
Хотя чтение и запись из/в DBF - совсем не выбрать текстовыуюс строку, как в TXT-XML.
ДБФ это если перекинуть 1-2 больших таблицы. Все остальное от лукавого.
Прекрасно перекидываются справочники, документы и прочее. Главное - все видно, ЧТО выгружаешь, и ЧТО загружаешь.
при десятках таблиц и объектов обеспечить ссылочную целостность в выгружаемых данных задача нетривиальная. КД это все берет на себя.
да, обеспечивает. Но именно это и выходит боком - что там перенеслось, как - может быть вообще невообразимая мешанина.
Если интересно - я тут тему поднял про частный случай, где КД вообще лажу выдает.
Интересно, где?
А вот там, когда перегружаешь в базу, где те же самые объекты (для пользователя те же самые), которые в источнике, были введены вручную в приемник (с другими ИД).
Все. Накрывается медным тазом все - и КД, и ЗагрузкаВыгрузкаXML (ПереносМеждуИдентичнымиКонфигурациями).
А если надо внести изменения в какой нить 100 лет назад не тобой написанный перенос через ДБФ - можно сразу накрываться простыней и ползти на кладбище.
Ничего подобного. С нуля делать - да, нужно четкую структуру разрабатывать, не совсем просто. А изменения вносить - спросите у vkr, сколько десятков он переносов сделал на основе одной своей разработки.
В такие моменты понимаешь прелести КД.
"прелести" могут быть полностью нивелированы её недостатками. Зависит от того, с чем столкнетесь.
ЗЫ: Еще ДБФ хорош любителям поперебирать ручками таблицы (а-ля 7.7) выбратьстроки() получитьстроку() - удовольствие (сомнительное) получает махровый прогер, а оплачивает часы разработки предприятие.
а ничего, что серьезная перегрузка через XML чисто технически (выгрузка данных - загрузка данных) равна по времени разработке переноса на DBF+сам перенос. А ведь надо еще сделать и отладить правила....
Почитайте первый мой пост в этой теме - выгрузка из 7.7 через КД составила СУТКИ!!! А у меня ведь далекко не самый большой справочник был - всего-то 30тыс записей в одной базе, 25 - в другой... Загружать эту фигню полученную я уже не стал - исходя из десятков переносов, сделанных на КД, я прекрасно знаю, сколько раз мне еще придется туда-сюда перегружать эти XML, править правила в КД, опять перегружать, чтобы все встало на место.
Поэтому потратил полтора рабочих дня на разработку переноса на DBF, и за считанные СЕКУНДЫ!!! перенес все, что надо. Да, тоже не сразу. Но, извините, я в течении следующих суток могу поправить все, что надо, а не ждать, пока за это время всего лишь одна выгрузка XML пройдет.
Так что против фактов не попрешь, как бы не хотелось кому-то все под общую гребенку гнать и агитировать за любимую игрушку, даже не сталкиваясь с вышеперечисленными проблемами.
а "выбратьстроки() получитьстроку()" - это очень хорошо, что у тебя все под контролем. А не "я вам все сделал - давайте деньги, и ловите потом меня в поле, какую я вам там в новой базе свалку устроил!"
Хотя чтение и запись из/в DBF - совсем не выбрать текстовыуюс строку, как в TXT-XML.
(48)(49) AlexO,
я уже писал что перенос через ДБФ хорош для переноса большого количества однородных данных. Когда 2-3-5 таблиц без сложных отношений между собой.
Когда встает необходимость перенести сложносвязанные данные удобнее использовать КД.
Да у нее существенно ниже скорость переноса, но существенно выше скорость разработки.
Не знаю какой справочник вы переносили сутки и 30000 записей.
Буквально сегодня была потребность перенести 20000 позиций номенклатуры и 5000 контрагентов с договорами и банковскими счетами.
Разработка правил - 20 минут, сам перенос 10. Сомневаюсь что написал бы перенос тех 3 десятков объектов через ДБФ за эти полчаса.
По скорости КД - очень существенное влияние оказывают галочки "Переносить объекты по ссылкам" и "Запоминать выгруженные объекты". Главное понимать механизмы переноса и правильно их использовать.
я уже писал что перенос через ДБФ хорош для переноса большого количества однородных данных. Когда 2-3-5 таблиц без сложных отношений между собой.
Когда встает необходимость перенести сложносвязанные данные удобнее использовать КД.
Да у нее существенно ниже скорость переноса, но существенно выше скорость разработки.
Не знаю какой справочник вы переносили сутки и 30000 записей.
Буквально сегодня была потребность перенести 20000 позиций номенклатуры и 5000 контрагентов с договорами и банковскими счетами.
Разработка правил - 20 минут, сам перенос 10. Сомневаюсь что написал бы перенос тех 3 десятков объектов через ДБФ за эти полчаса.
По скорости КД - очень существенное влияние оказывают галочки "Переносить объекты по ссылкам" и "Запоминать выгруженные объекты". Главное понимать механизмы переноса и правильно их использовать.
(53)
Извините, не в тему напишу чуть-чуть.
Эх. Завидую я вам - молодым. ;-)
А у меня в системе нет никакого переноса.
Экспорт/импорт в файл печатных документов - есть. Чтобы не набивать в другой системе (в другой конторе) документы с бумажки. Форматы разные - как получатель запрашивает. А переноса - нетУ... Переносить некуда. База данных одна, "конфигурация" (в терминах 1С-а) - одна. Скучная жизнь у меня. ;-)
Помню, делал перенос. Давно. На стыке 80-х и 90-х годов. С магнитной ленты "формата" IBM 360/370 на жесткий диск "формата" IBM PC. База данных спектральной, структурной и фактографической информации. Органическая химия. Спектральный анализ. Банк данных мы такой делали. Система называлась - "2S". ;-) Один раз перенесли - и всё. Разработка "правил" переноса заняла квартал. Это вместе с распайкой устройства сопряжение EC-9004 по RS-232 c IBM PC. А перенос занял пару рабочих дней...
Эх. Завидую... У вас много интересной работы. И всегда вы при деле и зарплате. Работе - измеряемой в часах, а не в результатах... :-)
Извините, не в тему напишу чуть-чуть.
Эх. Завидую я вам - молодым. ;-)
А у меня в системе нет никакого переноса.
Экспорт/импорт в файл печатных документов - есть. Чтобы не набивать в другой системе (в другой конторе) документы с бумажки. Форматы разные - как получатель запрашивает. А переноса - нетУ... Переносить некуда. База данных одна, "конфигурация" (в терминах 1С-а) - одна. Скучная жизнь у меня. ;-)
Помню, делал перенос. Давно. На стыке 80-х и 90-х годов. С магнитной ленты "формата" IBM 360/370 на жесткий диск "формата" IBM PC. База данных спектральной, структурной и фактографической информации. Органическая химия. Спектральный анализ. Банк данных мы такой делали. Система называлась - "2S". ;-) Один раз перенесли - и всё. Разработка "правил" переноса заняла квартал. Это вместе с распайкой устройства сопряжение EC-9004 по RS-232 c IBM PC. А перенос занял пару рабочих дней...
Эх. Завидую... У вас много интересной работы. И всегда вы при деле и зарплате. Работе - измеряемой в часах, а не в результатах... :-)
(54) hogik,
:) действительно скучно
а у нас в месяц 1-2 новых проекта по переводу с чего-то там на что-то еще.
И каждый раз перенос, обучение, смена бизнес-процессов.
А насчет часов, вы не правы: на почасовке только обучение. Остальное - твердая сумма за сданный проект/доработку/отчет. Оплата - по сдаче результата.
:) действительно скучно
а у нас в месяц 1-2 новых проекта по переводу с чего-то там на что-то еще.
И каждый раз перенос, обучение, смена бизнес-процессов.
А насчет часов, вы не правы: на почасовке только обучение. Остальное - твердая сумма за сданный проект/доработку/отчет. Оплата - по сдаче результата.
(55)
Константин (GreyJoJo).
"смена бизнес-процессов"(с) - это выше моего понимания. У нас и "бизнес процесс" - один. И он не меняется вот уже десять лет. Может поэтому мне и безразлично в каком формате осуществлять "обмен" информацией?
Константин (GreyJoJo).
"смена бизнес-процессов"(с) - это выше моего понимания. У нас и "бизнес процесс" - один. И он не меняется вот уже десять лет. Может поэтому мне и безразлично в каком формате осуществлять "обмен" информацией?
(57)
Константин (GreyJoJo).
И все же. Без шуток.
"реляционный хорош при переносе больших объемов"(с)
"При переносе сложных структур в использовании удобнее иерархический подход"(с)
А что выбрать, если объем большой и структура сложная?
Константин (GreyJoJo).
И все же. Без шуток.
"реляционный хорош при переносе больших объемов"(с)
"При переносе сложных структур в использовании удобнее иерархический подход"(с)
А что выбрать, если объем большой и структура сложная?
(58) hogik,
Если серьезно:
На практике такое встречается при "разовых" переносах: миграции с одной ИС на другую.
В этом случае мы используем комбинированный подход:
Основную массу таблиц переносили "Иерархическим" методом - т.е. через КД. (как правило справочники)
Особо крупные и проблемные таблицы тащили "Реляционным" методом. (документы ввода остатков с большим количеством записей).
основных критериев 2:
1) Стоимость - львиную часть составляет ЗП специалиста, стоимость машинного времени обычно ничтожна мала. И нет существенно разницы перенос делается минуту или час, главное насколько быстро он пишется.
2) временные рамки - при переходах есть промежуток времени, в течении которого данные должны быть перенесены в новую БД для начала работы. Обычно это "ночь", "выходные" и.т.д. набор данных - остатки. Тут стоимость отходит на второй план.
Когда то довелось работать в крупной торговой сети - там данные собирались с нескольких тысяч торговых точек со всей России и мигрировали по нескольким ИС в центральном офисе. Там использовались "реляционные" методы, но и стоимость разработок и изменений была астрономической.
По большому счету это исключение из практики использования 1С.
Если серьезно:
На практике такое встречается при "разовых" переносах: миграции с одной ИС на другую.
В этом случае мы используем комбинированный подход:
Основную массу таблиц переносили "Иерархическим" методом - т.е. через КД. (как правило справочники)
Особо крупные и проблемные таблицы тащили "Реляционным" методом. (документы ввода остатков с большим количеством записей).
основных критериев 2:
1) Стоимость - львиную часть составляет ЗП специалиста, стоимость машинного времени обычно ничтожна мала. И нет существенно разницы перенос делается минуту или час, главное насколько быстро он пишется.
2) временные рамки - при переходах есть промежуток времени, в течении которого данные должны быть перенесены в новую БД для начала работы. Обычно это "ночь", "выходные" и.т.д. набор данных - остатки. Тут стоимость отходит на второй план.
Когда то довелось работать в крупной торговой сети - там данные собирались с нескольких тысяч торговых точек со всей России и мигрировали по нескольким ИС в центральном офисе. Там использовались "реляционные" методы, но и стоимость разработок и изменений была астрономической.
По большому счету это исключение из практики использования 1С.
(59)
Константин (GreyJoJo).
Вроде всё у Вас логично написано. При разовой миграции иначе и не бывает.
Но, если в конторе используется множество баз данных с различной схемой базы данных. Обмен данными требуется регулярно по постоянным "правилам обмена". Объем большой и структура сложная. Скорость обмена критична. Разработка делается один раз на многие годы. Продолжаем использовать КД с XML-ям?
Или это тоже "исключение из практики использования 1С"(с) ?
Константин (GreyJoJo).
Вроде всё у Вас логично написано. При разовой миграции иначе и не бывает.
Но, если в конторе используется множество баз данных с различной схемой базы данных. Обмен данными требуется регулярно по постоянным "правилам обмена". Объем большой и структура сложная. Скорость обмена критична. Разработка делается один раз на многие годы. Продолжаем использовать КД с XML-ям?
Или это тоже "исключение из практики использования 1С"(с) ?
(60) hogik,
Опять же отталкиваясь из текущей практики:
1) регулярные обмены используются для переноса между оперативной, аналитической и регламентированнми БД - обмены типовые, скорость не критична (ночь длинна... :) ) клиенту за полчаса настраивается типовой и вперед;
2) обмены с филиалами/торговыми точками - тут скорость критична. Если хватает скорости типовых схем их и используем. Если не хватает (как в приведенном примере) да используем "реляционный" метод :).
Но повторюсь: крупных сетей у нас в провинции почти нет. Случаи написания таких обменов - единичны.
ЗЫ: есть исключения - перенос из раритетов типа СБИСа. Тут никуда не деться разбираем ДБФ/ТХТ.
Я не говорю что какая та из методик однозначно лучше или хуже - все зависит от потребностей, просто чаще удобна именно КД, поэтому я ее и защищаю.
Опять же отталкиваясь из текущей практики:
1) регулярные обмены используются для переноса между оперативной, аналитической и регламентированнми БД - обмены типовые, скорость не критична (ночь длинна... :) ) клиенту за полчаса настраивается типовой и вперед;
2) обмены с филиалами/торговыми точками - тут скорость критична. Если хватает скорости типовых схем их и используем. Если не хватает (как в приведенном примере) да используем "реляционный" метод :).
Но повторюсь: крупных сетей у нас в провинции почти нет. Случаи написания таких обменов - единичны.
ЗЫ: есть исключения - перенос из раритетов типа СБИСа. Тут никуда не деться разбираем ДБФ/ТХТ.
Я не говорю что какая та из методик однозначно лучше или хуже - все зависит от потребностей, просто чаще удобна именно КД, поэтому я ее и защищаю.
(61)
Константин (GreyJoJo).
Ну - вот. А Вы хотели откланяться раньше времени. ;-)
Так бы и осталось впечатление о Вашей позиции по (37) сообщению.
А на (61) сообщении становится понятно, что и Вам иногда приходится "поперебирать ручками таблицы"(с)
"За сим откланиваюсь..."(с)
Желаю успехов.
P.S. В нашем ларьке "ночь длинна... "(с) один раз в году - на 1 января. Поэтому у нас и нет никакого "обмена" данными в понимание 1С-КД. Не буду повторять 4 пункт из своего (43) сообщения.
Константин (GreyJoJo).
Ну - вот. А Вы хотели откланяться раньше времени. ;-)
Так бы и осталось впечатление о Вашей позиции по (37) сообщению.
А на (61) сообщении становится понятно, что и Вам иногда приходится "поперебирать ручками таблицы"(с)
"За сим откланиваюсь..."(с)
Желаю успехов.
P.S. В нашем ларьке "ночь длинна... "(с) один раз в году - на 1 января. Поэтому у нас и нет никакого "обмена" данными в понимание 1С-КД. Не буду повторять 4 пункт из своего (43) сообщения.
(53) GreyJoJo,
[quota]сам перенос - 10[/quota]
это время выгрузки из 1с8 файла небольшого (1-2 тыс объектов) файла. Выгрузка 5 тыс объектов из 1с8 - 20 мин. Чтение - полчаса-минут сорок.
А вот их 1с7 меня же выгружалось сутки 30 тыс наименований номенклатуры (всего - 69 тыс выгруженных объектов).
И никаких "10 мин" на чтение немаленьких текстовых файлов в 1с никогда не было и не будет :)
[quota]сам перенос - 10[/quota]
это время выгрузки из 1с8 файла небольшого (1-2 тыс объектов) файла. Выгрузка 5 тыс объектов из 1с8 - 20 мин. Чтение - полчаса-минут сорок.
А вот их 1с7 меня же выгружалось сутки 30 тыс наименований номенклатуры (всего - 69 тыс выгруженных объектов).
И никаких "10 мин" на чтение немаленьких текстовых файлов в 1с никогда не было и не будет :)
(68) GreyJoJo,
ну не было на разных компах ли, серверах ли того, что вы говорите (на серверах - да, чуть побыстрей, но не намного) - не пишутся текстовые файлы в 1с быстро (а читаются - еще дольше, минимум в полтора раза медленнее, и чем больше объем такого файла - тем все медленнее и медленнее). Не было в сравнимых объемах - таких затрат времени, как у вас.
И моя статистика по времени переносов (как и обменов) полностью соответствует приведенной мной выше с погрешностью 10%.
ну не было на разных компах ли, серверах ли того, что вы говорите (на серверах - да, чуть побыстрей, но не намного) - не пишутся текстовые файлы в 1с быстро (а читаются - еще дольше, минимум в полтора раза медленнее, и чем больше объем такого файла - тем все медленнее и медленнее). Не было в сравнимых объемах - таких затрат времени, как у вас.
И моя статистика по времени переносов (как и обменов) полностью соответствует приведенной мной выше с погрешностью 10%.
(69)(70)
Если обсуждать "скорость форматов" и программных средств использующих эти "форматы", то фразы типа "а у меня" не имеют никакого смысла. Думаю, надо более подробно рассматривать саму суть задач. Т.е. время "сутки" и "пять минут" на выполнение, как бы, равноценных задач в равноценных средах - ТакогоНеМожетБыть. ;-)
Если обсуждать "скорость форматов" и программных средств использующих эти "форматы", то фразы типа "а у меня" не имеют никакого смысла. Думаю, надо более подробно рассматривать саму суть задач. Т.е. время "сутки" и "пять минут" на выполнение, как бы, равноценных задач в равноценных средах - ТакогоНеМожетБыть. ;-)
(72)
Константин (GreyJoJo).
Повторю: "надо более подробно рассматривать саму суть задач"(с).
А - так? ;-) Например, я выгружаю38'750'000'000 38'750'000 записей за 295 секунд.
В DBF формат с обеспечением ссылочной целостности. :-)
Константин (GreyJoJo).
Повторю: "надо более подробно рассматривать саму суть задач"(с).
А - так? ;-) Например, я выгружаю
В DBF формат с обеспечением ссылочной целостности. :-)
(65) AlexO,
Если хотите конкретные цифры.
База клиента КА 1.1 - клиент сервер. Рабочая станция - ноут проц Т4400, 4 гига оперативки.
Справочник номенклатуры 10228 элементов.
Выгрузка справочника со всеми зависимыми объектами:
Начало выгрузки: 28.05.2012 13:57:27
Выгружено объектов: 24 368
Окончание выгрузки: 28.05.2012 14:02:39
итого 5 минут 12 секунд
Выгрузка без зависимых объектов:
Начало выгрузки: 28.05.2012 14:08:58
Выгружено объектов: 10 228
Окончание выгрузки: 28.05.2012 14:11:04
2 минуты 6 секунд
так что утверждение "это время выгрузки из 1с8 файла небольшого (1-2 тыс объектов) файла. Выгрузка 5 тыс объектов из 1с8 - 20 мин. " не подтверждается как минимум на порядок.
Загрузка в аналогичную файловую базу:
Загрузка с подчиненными справочниками:
Начало загрузки: 28.05.2012 15:10:25
Загружено объектов: 24 368
Окончание загрузки: 28.05.2012 15:14:12
3 минуты 47 секунд
без подчиненных:
Начало загрузки: 28.05.2012 15:18:49
Загружено объектов: 10 228
Окончание загрузки: 28.05.2012 15:20:24
1 минута 35 секунд
"Чтение - полчаса-минут сорок. " - разница на порядок.
Если хотите конкретные цифры.
База клиента КА 1.1 - клиент сервер. Рабочая станция - ноут проц Т4400, 4 гига оперативки.
Справочник номенклатуры 10228 элементов.
Выгрузка справочника со всеми зависимыми объектами:
Начало выгрузки: 28.05.2012 13:57:27
Выгружено объектов: 24 368
Окончание выгрузки: 28.05.2012 14:02:39
итого 5 минут 12 секунд
Выгрузка без зависимых объектов:
Начало выгрузки: 28.05.2012 14:08:58
Выгружено объектов: 10 228
Окончание выгрузки: 28.05.2012 14:11:04
2 минуты 6 секунд
так что утверждение "это время выгрузки из 1с8 файла небольшого (1-2 тыс объектов) файла. Выгрузка 5 тыс объектов из 1с8 - 20 мин. " не подтверждается как минимум на порядок.
Загрузка в аналогичную файловую базу:
Загрузка с подчиненными справочниками:
Начало загрузки: 28.05.2012 15:10:25
Загружено объектов: 24 368
Окончание загрузки: 28.05.2012 15:14:12
3 минуты 47 секунд
без подчиненных:
Начало загрузки: 28.05.2012 15:18:49
Загружено объектов: 10 228
Окончание загрузки: 28.05.2012 15:20:24
1 минута 35 секунд
"Чтение - полчаса-минут сорок. " - разница на порядок.
DBF хоть и старый формат, но как-то привычнее. А если ещё размеры файлов предполагаются большие, то DBF лучше и надежнее...Этот формат был очень популярным в 1с 7.7.
DBF, при правильном подходе работает на порядки быстрее остальных типов данных,
но для быстрого написания постоянного обмена между разнородными конфами, нужен свой составитель обмена, по типу 1С-ой конвертации данных.
Такие "составители" существуют, но они далеки до идеала.
Сто раз порывался было написать идеальный составитель для обмена по dbf (опыта хватает), но каждый раз "откладывалось".
но для быстрого написания постоянного обмена между разнородными конфами, нужен свой составитель обмена, по типу 1С-ой конвертации данных.
Такие "составители" существуют, но они далеки до идеала.
Сто раз порывался было написать идеальный составитель для обмена по dbf (опыта хватает), но каждый раз "откладывалось".
хм... извините за "теорию заговоров", но возможно 1с целенаправленно отходит от работы с условно кросс-платформенными решениями( условно отнесем к ним ДБФ формат) , для 6 и 7 версии возможно было написать обработки на тех же "сях" которые работали на дбф-ных базах 1с на порядок быстрее средств встроенного языка. Для файловой 8-ки остается только кривоватый и медленный ком интерфейс, требующий к тому же неплохих знаний встроенного языка, 1сник становится все более платформо зависимым программистом, который никогда не уведет клиента под другую программу, просто потому, что не сможет писать , без серьезной переподготовки, ни на чем другом.
(74) К слову, работа напрямую с файлами dbf и таблицами sql программных продуктов 1С:Предприятия нарушает лицензионное соглашение. На счёт авторских прав не помню, но, кажется, тоже. А если да - то по ст.146 УК РФ до двух лет (по части 3 до шести лет).
(1) Похоже, обсуждение заглохло, а жаль. Транспорт данных между базами тема обширная.
Перепробовал в разное время и текстовые файлы и ДБФ, и ХМЛ, и СОМ, и ВС. На данный момент ДБФ пользую для обмена со сторонними программами контрагентов, которые не потребляют ХМЛ. Аргументы могу выдвинуть следующие:
1. ХМЛ, как ни крути, на данный момент является в программировании стандартом сериализации данных де-факто, в то время как ДБФ не знаю даже используется ли ещё где-нибудь кроме 1С 7.7 и прочих программ, разработанных в 80-90х годах. Если смотреть на перспективу обмена с новыми не-1С системами, то они и вовсе могут не поддерживать ДБФ.
2. Формат более гибкий, нежели ДБФ с его ограничениями, тянущимися со времён МС-ДОС, ФАТ-16 и 640кБ оперативной памяти.
3. Структура данных описывается вместе с данными и есть возможность хранения наборов данных разной стурктуры в одном файле.
4. Человекочитаемый формат.
Вообще, сторонники ДБФ, как мне показалось при чтении данной ветки, говоря об "обмене через ХМЛ", мешают в одну кучу три, в общем-то, разных понятия:
1. Собственно стандарт ХМЛ.
2. Универсальный обмен, правила обмена и КД.
3. Правила обмена, поставляемые фирмой 1С для типовых конфигураций.
Потому, высказывания типа
(1) Похоже, обсуждение заглохло, а жаль. Транспорт данных между базами тема обширная.
Перепробовал в разное время и текстовые файлы и ДБФ, и ХМЛ, и СОМ, и ВС. На данный момент ДБФ пользую для обмена со сторонними программами контрагентов, которые не потребляют ХМЛ. Аргументы могу выдвинуть следующие:
1. ХМЛ, как ни крути, на данный момент является в программировании стандартом сериализации данных де-факто, в то время как ДБФ не знаю даже используется ли ещё где-нибудь кроме 1С 7.7 и прочих программ, разработанных в 80-90х годах. Если смотреть на перспективу обмена с новыми не-1С системами, то они и вовсе могут не поддерживать ДБФ.
2. Формат более гибкий, нежели ДБФ с его ограничениями, тянущимися со времён МС-ДОС, ФАТ-16 и 640кБ оперативной памяти.
3. Структура данных описывается вместе с данными и есть возможность хранения наборов данных разной стурктуры в одном файле.
4. Человекочитаемый формат.
Вообще, сторонники ДБФ, как мне показалось при чтении данной ветки, говоря об "обмене через ХМЛ", мешают в одну кучу три, в общем-то, разных понятия:
1. Собственно стандарт ХМЛ.
2. Универсальный обмен, правила обмена и КД.
3. Правила обмена, поставляемые фирмой 1С для типовых конфигураций.
Потому, высказывания типа
делал через DBF - выгрузка заняла 2,5 минуты. До этого - сутки выгружалось через правила КД в XML.
- это претензии к пункту 3 (там действительно бывают перлы, заставляющие усомниться в умственном здоровье тех, кто эти правила разрабатывал), а не по первым двум. Можно использовать формат ХМЛ формируя структуру данных программно и не пользуясь универсальным обменом и КД, и тогда производительность уже будет зависеть от реализации конкретного драйвера/парсера и оптимизированности работы платформы с этими драйверами, а от формата представления данных - всё же в меньшей степени.
(75) saiten,
пусть тогда дадут качественный интерфейс обмена. А не лозунги и агитки.
ну это вы загнули :)
авторские права на что - на саму возможность что-то вытаскивать по открытому стандарту SQL или DBF?
К слову, работа напрямую с файлами dbf и таблицами sql программных продуктов 1С:Предприятия нарушает лицензионное соглашение.
пусть тогда дадут качественный интерфейс обмена. А не лозунги и агитки.
На счёт авторских прав не помню,
ну это вы загнули :)
авторские права на что - на саму возможность что-то вытаскивать по открытому стандарту SQL или DBF?
(76)
авторские права на что - на саму возможность что-то вытаскивать по открытому стандарту SQL или DBF?
Именно:
пусть тогда дадут качественный интерфейс обмена. А не лозунги и агитки.
Я бы тоже не отказался :) Только когда это в 1С думали о пользователях и уж тем более о программистах?
(77) saiten,
а вот и нет. Авторские права - на структуру базы 1С. А не на средства/методы открытых стандартов, которые 1с использует для своих баз без зазрения, всячески портя и скрывая свои "авторские разработки".
Именно: тыц
а вот и нет. Авторские права - на структуру базы 1С. А не на средства/методы открытых стандартов, которые 1с использует для своих баз без зазрения, всячески портя и скрывая свои "авторские разработки".
(78)
Из комментария к статье по той же ссылке:
Авторские права - на структуру базы 1С. А не на средства/методы открытых стандартов
Из комментария к статье по той же ссылке:
2. В соответствии с п. 1 комментируемой статьи содержание исключительного права изготовителя базы данных составляет возможность извлечения из базы данных входящих в нее материалов и их последующее использование в любой форме и любым способом.
Никто не вправе извлекать из базы данных материалы и использовать их без разрешения правообладателя – изготовителя базы данных
Никто не вправе извлекать из базы данных материалы и использовать их без разрешения правообладателя – изготовителя базы данных
(79) saiten,
учитесь работать с юридическими документами :)
Выдержка, которую Вы привели - это справедливо для баз 1с, созданных как формат 1с. Если создать базу SQL (DBF) средствами 1С, то извлекать оттуда данные можно как угодно и чем угодно.
Смысл моего предыдущего сообщения был в другом: 1с активно использует свободные лицензии, но очень жестко блюдет свои "разработки".
учитесь работать с юридическими документами :)
Выдержка, которую Вы привели - это справедливо для баз 1с, созданных как формат 1с. Если создать базу SQL (DBF) средствами 1С, то извлекать оттуда данные можно как угодно и чем угодно.
Смысл моего предыдущего сообщения был в другом: 1с активно использует свободные лицензии, но очень жестко блюдет свои "разработки".
(81) saiten,
данные принадлжеат владельцу данных - и это не фирма 1с.
просматривается лишь запрет извлекать именно из 1С-овой базы (CD, SQL), структура и логика которой и является собственностью 1с.
А не данные, в ней хранящиеся.
Короче говоря, запрещен "реинжиниринг" структуры баз, дабы все покупали 1с-сервер.
там явно говорится именно о данных
данные принадлжеат владельцу данных - и это не фирма 1с.
просматривается лишь запрет извлекать именно из 1С-овой базы (CD, SQL), структура и логика которой и является собственностью 1с.
А не данные, в ней хранящиеся.
Короче говоря, запрещен "реинжиниринг" структуры баз, дабы все покупали 1с-сервер.
(84)
И чтение тоже, дабы все покупали клиентские лицензии.
данные принадлжеат владельцу данных - и это не фирма 1с.
Кому принадлежат данные - это значения не имеет. В данном случае важно, что извлекать данные из базы имеет только создатель базы данных. Правообладателем продуктов 1С:Предприятия является фирма 1С, все остальные пользуются неисключительным правом.
Короче говоря, запрещен "реинжиниринг" структуры баз, дабы все покупали 1с-сервер.
И чтение тоже, дабы все покупали клиентские лицензии.
(87) saiten,
не важно и не создатель.
Если вы каким-то образом (скажем, Майкрософт ввел новую фичу в MS SQL) сможете, скажем, "сырую" базу 1с выгрузить в TXT, и оттуда "убрать" всю инфо о структуре хранения от 1с, оставив только данные - то читатйте эти данные сколько угодно и чем угодно.
как раз за чтение 1с денег с вас еще брать не додумалась :)
и что? А дубовые формы в 1с - формируются на основе dll Виндовс.
1с не платит за Линукс, хотя на винду, в которой разрабатывает, должна приобрести лицензию.
Майкрософт не делает тайны из формата XLS. НЕт тайн и в стандарте XML.
Но есть полнейшие и вопиющие несуразицы и недоделки во всем, где стоит клеймо "1с".
В данном случае важно, что извлекать данные из базы имеет только создатель базы
не важно и не создатель.
Если вы каким-то образом (скажем, Майкрософт ввел новую фичу в MS SQL) сможете, скажем, "сырую" базу 1с выгрузить в TXT, и оттуда "убрать" всю инфо о структуре хранения от 1с, оставив только данные - то читатйте эти данные сколько угодно и чем угодно.
И чтение тоже,
как раз за чтение 1с денег с вас еще брать не додумалась :)
Линукс - исполнительная платформа
и что? А дубовые формы в 1с - формируются на основе dll Виндовс.
1с не платит за Линукс, хотя на винду, в которой разрабатывает, должна приобрести лицензию.
Майкрософт не делает тайны из формата XLS. НЕт тайн и в стандарте XML.
Но есть полнейшие и вопиющие несуразицы и недоделки во всем, где стоит клеймо "1с".
(93)
Думаю, в 1С с вами не согласятся. Допустим, у меня есть 50 девочек, которые вбивают первичку - для этого им нужны данные из базы: справочники, значения регистров и т.п. Я должен приобрести для них лицензий на 150 килорублей, а вместо этого я пишу собственные клиенты и сервер, который напрямую из скуля цепляет нужные мне данные и передаёт на клиенты девочкам. Сформированные доки записываются в мою таблицу, а оттуда пакетом фигачатся в 1С, может быть даже средствами 1С с задействованием одной лицензии. И всех затрат: юсер КАЛ лицензия на скуль за 7 килорублей. Экономия в действии.
Если вы каким-то образом (скажем, Майкрософт ввел новую фичу в MS SQL) сможете, скажем, "сырую" базу 1с выгрузить в TXT, и оттуда "убрать" всю инфо о структуре хранения от 1с, оставив только данные - то читатйте эти данные сколько угодно и чем угодно.
Думаю, в 1С с вами не согласятся. Допустим, у меня есть 50 девочек, которые вбивают первичку - для этого им нужны данные из базы: справочники, значения регистров и т.п. Я должен приобрести для них лицензий на 150 килорублей, а вместо этого я пишу собственные клиенты и сервер, который напрямую из скуля цепляет нужные мне данные и передаёт на клиенты девочкам. Сформированные доки записываются в мою таблицу, а оттуда пакетом фигачатся в 1С, может быть даже средствами 1С с задействованием одной лицензии. И всех затрат: юсер КАЛ лицензия на скуль за 7 килорублей. Экономия в действии.
(94) чисто теоретически вы можете так сделать. почему нет? с таким же успехом можно платить лицензии за круг изобретателю колеса, однако ж никто не платит. Просто на практике записать доки в базу точно также как делает это 1С, несколько сложнее, чем может показаться на первый взгляд. С чтением все проще. Некоторые обмены так делают с сайтами всякими, читают напрямую.
(95)
А по поводу того, что так делают - ну, это, по принципу "не пойман - не вор", т.е. просто никто это проверять и привлекать за это не будет - оно никому не нужно и даже вредно для имиджа фирмы. А вот если сделать тиражное решение, которое реализует часть функционала 1С:предприятия в обход сервера 1С, и продавать его, то возьмутся с пристрастием.
почему нет?
А по поводу того, что так делают - ну, это, по принципу "не пойман - не вор", т.е. просто никто это проверять и привлекать за это не будет - оно никому не нужно и даже вредно для имиджа фирмы. А вот если сделать тиражное решение, которое реализует часть функционала 1С:предприятия в обход сервера 1С, и продавать его, то возьмутся с пристрастием.
(96) вообще не катит, я этот закон уже чуть ли не наизусть знаю. так, вот исключительный изготовитель БД, - это правообладатель этими данными, то есть пользователь, а СУБД - уж никак не 1С, это либо микрософты, либо чья еще СУБД. 1С здесь никаким боком. Если это так, приведите хоть 1 прецедент оного.
ЗЫ. Вообще я не сторонник этого метода, но хочется узнать объективные причины, почему этого делать нельзя. Пока не услышал.
ЗЫ. Вообще я не сторонник этого метода, но хочется узнать объективные причины, почему этого делать нельзя. Пока не услышал.
(96) saiten, да и еще вы путаете, прошу прощения, хрен с пальцем.
Одно дело - изменять свои данные в СУБД, которой пользуется клиент-серверное приложение 1С. (кстати сказать к файловой версии ваш довод вполне обоснован. права на файловую версию принадлежат исключительно 1С)
Другое дело - создать свой клиент, повторяющий функционал клиент-серверного приложения 1С, в части механизмов работы с СУБД и продавать его. По моему очевидно нарушение закона, хотя бы в части плагиата.
Одно дело - изменять свои данные в СУБД, которой пользуется клиент-серверное приложение 1С. (кстати сказать к файловой версии ваш довод вполне обоснован. права на файловую версию принадлежат исключительно 1С)
Другое дело - создать свой клиент, повторяющий функционал клиент-серверного приложения 1С, в части механизмов работы с СУБД и продавать его. По моему очевидно нарушение закона, хотя бы в части плагиата.
(94) saiten,
тогда расскажите, как без вскрытия логики и связей таблиц 1с-базы вы такой клиент напишите :)
тут уже бесчетное число раз и по разным вопросам порывались "писать" убийцу 1с-сервера.
Я просто уже устал уже спорить с каждым новым поколением.
а вместо этого я пишу собственные клиенты и сервер
тогда расскажите, как без вскрытия логики и связей таблиц 1с-базы вы такой клиент напишите :)
тут уже бесчетное число раз и по разным вопросам порывались "писать" убийцу 1с-сервера.
Я просто уже устал уже спорить с каждым новым поколением.
(97)
(99)
(101) Вот это, кстати, верное замечание...
тогда расскажите, как без вскрытия логики и связей таблиц 1с-базы вы такой клиент напишите :)
Тогда расскажите, как без вскрытия логики и связей вы получите хотябы что-нибудь из базы 1с скуль-запросом. Вы получите контактную информацию, но без указания того, к кому она относится - очень полезно. Получите документы реализации, но без ссылок на организацию, контрагента и номенклатуру. И т.п. Для этого надо сделать джойн зная структуру таблиц и связей.
(99)
ак, вот исключительный изготовитель БД, - это правообладатель этими данными, то есть пользователь, а СУБД - уж никак не 1С, это либо микрософты, либо чья еще СУБД. 1С здесь никаким боком.
Ну и кто тут путает что с чем? Речь не о лицензировании СУБД или чего-нибудь ещё, а о базе данных, как продукте интеллектуальной деятельности - структуре данных и иже с ней. Если вы выгрузите в мдб базу - это будет плагиат, грубо говоря, торгуя левым софтом - не важно на что вы его запишете: на двд, блю рэй или флэшку. Субд в данном случае - носитель и не более того.
Другое дело - создать свой клиент, повторяющий функционал клиент-серверного приложения 1С, в части механизмов работы с СУБД и продавать его.
а в чём разница кроме размера нанесённого ущерба-то?
(101) Вот это, кстати, верное замечание...
(106) saiten, Ну и кто тут путает что с чем? Где у меня хоть слово про mdb и т.д. ? Где у меня про торг этой базой ? Вы о чем, вы читали что я писал?
Вы знакомы с СУБД типа MS SQL? простейшую структуру можно получить без знаний 1С в принципе. и джоины, и что угодно. сделать простую выборку наименований товаров, помоему здесь нет ничего невозможного. ссылки, да можно IDRef в GUID перевести - вот и будет ссылка.
Вы знакомы с СУБД типа MS SQL? простейшую структуру можно получить без знаний 1С в принципе. и джоины, и что угодно. сделать простую выборку наименований товаров, помоему здесь нет ничего невозможного. ссылки, да можно IDRef в GUID перевести - вот и будет ссылка.
а в чём разница кроме размера нанесённого ущерба-то?
Ну если для вас нет разницы между контрафактной продажой программы Excel и прайсом, по волей судьбы оказавшимся в dbf, который читает программа Excel, который(прайс) пользователь может менять как ему угодно, то нам не о чем с вами разговаривать.
(108) cool.vlad4,
а это и есть создание 1с-сервера. И использование структуры и логики 1с-базы.
вот тут как раз и может 1с заявить о своих правах.
помоему здесь нет ничего невозможного. ссылки, да можно IDRef в GUID перевести
а это и есть создание 1с-сервера. И использование структуры и логики 1с-базы.
вот тут как раз и может 1с заявить о своих правах.
(110) cool.vlad4,
ничего не мешает. И вообще, всю обработку и хранение и поиск и извлечение данных можно было целиком возложить на MS SQL.
Но тут мы подошли к главной тайне 1с.
"мы не привязаны к одной платформе!", "у нас кроссплатформенная база!" - помните агитки 1с?
Так вот, все это вранье.
Они каждый раз и под каждую платформу все равно пишут свой уникальный дистриб базы, со всеми нюансами и переделками под платформу.
Так что же за причина делать то, что изначально некачественно и провально?
Деньги.
Закрытый код и аура "уникальная разработка" дают право привязывать клиентов лицензионным соглашением к безальтернативным разработкам 1с в СУБД, среде программирования, учетным программам...
Пусть сделано плохо, некачественно, откровенно глупо - но зато права собственности и безальтернативная дистрибьюция.
А уж врать и недоговаривать 1с учить не надо.
(111) saiten,
Конечно, не слыхали. Потому как это невозможно редактировать в ТЕКСТЕ огромный малосвязанных файл данных.
Это тоже самое, что искать в Войне и Мир, что сказал некий герой, когда сидел под каким-то растением.
Какой герой, когда, где - ищите...
Майкрософт никогда не делала секрета из своих офисных форматов. И ими пользуются и выгружают не потому, что они здорово как хороши, и уж не потому, что платны, а потому, что распространены.
Сравните подходы. Майкрософт - великая компания (несмотря на агрессивный маркетинг), а 1С - великий российский паразит. О чем я вам и толкую - про использование свободных лицензий, закрытость своих "решений", глухота к разработчикамм и их нуждам..
ну хорошо, что мешает гуид сгенерировать средствами СУБД
ничего не мешает. И вообще, всю обработку и хранение и поиск и извлечение данных можно было целиком возложить на MS SQL.
Но тут мы подошли к главной тайне 1с.
"мы не привязаны к одной платформе!", "у нас кроссплатформенная база!" - помните агитки 1с?
Так вот, все это вранье.
Они каждый раз и под каждую платформу все равно пишут свой уникальный дистриб базы, со всеми нюансами и переделками под платформу.
Так что же за причина делать то, что изначально некачественно и провально?
Деньги.
Закрытый код и аура "уникальная разработка" дают право привязывать клиентов лицензионным соглашением к безальтернативным разработкам 1с в СУБД, среде программирования, учетным программам...
Пусть сделано плохо, некачественно, откровенно глупо - но зато права собственности и безальтернативная дистрибьюция.
А уж врать и недоговаривать 1с учить не надо.
(111) saiten,
Ну не слыхал - приведите пример, просветите, буду благодарен
Конечно, не слыхали. Потому как это невозможно редактировать в ТЕКСТЕ огромный малосвязанных файл данных.
Это тоже самое, что искать в Войне и Мир, что сказал некий герой, когда сидел под каким-то растением.
Какой герой, когда, где - ищите...
про мдб действительно ... торг базой...
Майкрософт никогда не делала секрета из своих офисных форматов. И ими пользуются и выгружают не потому, что они здорово как хороши, и уж не потому, что платны, а потому, что распространены.
Сравните подходы. Майкрософт - великая компания (несмотря на агрессивный маркетинг), а 1С - великий российский паразит. О чем я вам и толкую - про использование свободных лицензий, закрытость своих "решений", глухота к разработчикамм и их нуждам..
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот