DBF юзают неудачники?
(122)
Это что - спор профессионалов или примитивная стычка??? Не могу удержаться от цитаты: "Огульное обвинение – обвинение в чем-то всех сразу, без разбора или недостаточно обоснованное обвинение. Недопустимо, несмотря на возможную острую ситуацию. Любое обвинение должно быть как-то обоснованным и достаточно адресным, в противном случае могут быть ошибки и справедливые обиды. Если во время сильного переживания вы допустили огульное обвинение, то позднее успокоившись и выяснив обстоятельства дела, извинитесь." Романова Н.Н., Филиппов А.В. Словарь. Культура речевого общения: этика, прагматика, психология, 2010 г.
(125) Послушай!... Еще раз (последний) попытаюсь обратится к твоему разуму и логике. Ты сделал недостойный, обидный вброс своим первым постом, огульно назвав специалистов, знающих и умеющих работать с ДБФ неудачниками. Дальше ты уже начал вилять - уточнять и оправдываться. Но общей негативной картины это не поменяло. Пропетлять не удастся! Вопрос: ты работаешь с форматами .mmo и .ext ? Что???!!! Ты даже не слышал о таких? - нуууу.... Тогда ты неудачник и фамилия твоя Пошелнакуй!
Ответили: (128)
(126) (127) господа, речь не идет об огульном обвинении.
Речь идет конкретно о задачах обмена в 1С и программистах, которые пишут на них обмены.
Поэтому сентенция Василия о других форматах не актуальна, т.к. обмены пишут 80% программистов, а указанные им форматы используют очень малое количество специалистов.
И кстати, напомните мне, позволяет ли Эксель добавить в DBF новые колонки, переименовать существующие или это только вьювер.
По сути с XML полная свобода - открывай в любом текстовом редакторе и правь по самое не балуй.
Ответили: (129)
(128) ну если ты не можешь редактировать DBF то это твои проблеммы, например есть один отчет который втягивается в определенную систему можно с помощью XML а можно и ДБФ так вот когда мне надо слить в кучу в один отчет три а то и четыре ДБФки я без проблем тремя нажатиями конопок AppendFrom добавляю (сливаю) в один сколько сколько мне нужно. Слей три XML !!!
А вот еще есть формат ZDI так твой XML и рядом не валялся, он просто нервно курит в туалете
Могу прислать два файла в которых один и тот же документ но пчему то XML в три раза тяжелей а тому формату ни парсеров не надо ни таблиц шаблонов нифига.
(129) "Слей три XML !!!" - в три клика точно не пролучится.
За ZDI - особое спасибо: в пылу спора забыл привести в качестве примера.
(131) Забей! - это не для тебя. Ты еще XML не наигрался. Бедные те, кто не успеют вовремя с тобой соскочить с XML на какой-то новый формат... - ты же их (сегодняшних твоих соратников) опять неудачниками обзывать будешь.
(115) fixin,
| Цитата |
|---|
| Ваша статья про XML-панацею - это статья не об использовании XML для целей обмена и уж никак не сравнение XML и DBF.
Статью просмотрел, автор недалекий практик-ретроград. Полоса пропускания решается сжатием. Возможность передачи сложноструктурированных данных (типа файла обмена РИБ) легко искупает некоторую избыточность формата. |
Странно, что Вы оспариваете общеизвестные вещи, недостатки, которые многократно описаны (в т.ч. в энциклопедии).
А насчет применения XML на практике приведу пример:
1 Ссылка.
"С 01.01.2004 г. вступила в силу новая редакция Таможенного кодекса, которая предусматривает:
использование новейших информационных технологий (впервые в новом Таможенном кодексе целая, отдельно взятая, глава посвящена применению информационных технологий в таможенном деле).
Применение с 01.01.2007 г. новой ГТД и xml-формата внешних данных привело к необходимости осуществления модернизации программных средств и структур баз данных (БД) как участников ВЭД, так и сотрудников таможенных органов.
Комплексная оценка объемов выполняемых работ как с одной, так и с другой стороны привела к выбору технологии гибкого перехода, который заключается в возможности применения двух внешних форматов таможенных деклараций (традиционного - dbf-структура и «нового» - xml-документа) в течение первого полугодия 2007 г.
Анализируя деятельность таможенных органов за указанный период, можно сделать вывод, что обработка внешних баз ГТД в виде xml-документа в полном объеме начал реализовываться лишь в ноябре 2007 г., т.е. на взаимную модификацию программных средств было затрачено больше времени, чем планировалось ранее.
2 ссылка:
"С 3 марта 2008 года все таможенные органы России при декларировании товаров участниками внешнеэкономической деятельности будут принимать документы, представленные в электронном виде, исключительно в XML-формате. "
3 ссылка
Ввод в действие с 1 января 2011 новых правил и нового формата выгрузки сильно поколебало налаженную систему таможенного оформления. Резко снизился поток зарегистрированных деклараций.
14.01.11 Нерешенные проблемы нового формата....."
... и далее много-много пунктов....
То есть жизнь полностью подтверждает слова Дон Петерсона, которые я цитировала в посте 112.
- Незнание
- Глупость
- Жадность
Ответили: (134)
Кроме 1с есть много других систем и не все они умеют работать с XML. А интеграция порой необходима. Поэтому юзали,юзаем и будем юзать для обмена и DBF, и текстовые файлы, и прямой запрос SQL, и OBDC, и BDE. Универсальных решений не существует, это утопие. А вот не умение ими пользоваться - ЭТО ОТСТОЙ....
(135) Знаешь... Я бы добавил: если что-то я могу сделать быстро, красиво и главное удобно, то не вижу ни разу причин поддаваться общему психозу планктона только потому, что это сегодня модно, и не изголятся ради фиг знает чего. Если что-то можно сделать попроще - его и надо делать просто, а не выпендриваться.
А спорить с автором топика абсолютно бесполезно. Это еще хуже, чем дуру "иметь" - только член тупить.
Ответили: (137)
(138) fixin, а если я могу написать обмен и с помощью ДБФ и с помощью ХМЛ, но выбираю для своей задачи ДБФ, хотя в принципе мог бы и с помощью ХМЛ, то я тоже буду неудачником? Просто исходя из вашей логики, я понял что неудачник тот, кто не хочет познавать новое, но если человек значит и то и другое, но для своей задачи решил использовать старое(дбф), то что тогда?
Ответили: (141)
(137) Конечно неудачникам "велик нужно еще освоить." - а я и так умею на нем ездить и весьма неплохо. А ты можешь даже не стараться - не освоишь, еще упадешь и так слабенькую голову покалечишь - и оно тебе надо?
ЗЫ: отвечаю спецом в твоем стиле. И ты еще смеешь после таких демаршей подымать в закрытой ветке вопроссы культуры общения? Засранец ты конченный! - Это не в нарушение правил, не мат - ибо до взрослого человека ты не дорос.
Ответили: (141)
(141) Я "готовлю" XML, где в этом есть необходимость и это проще, чем ДБФ, а ДБФ там, где оно проще, чем XML, а есть еще случаи, где ни то ни другое, а третье или четвертое. НЕ тупи. Можно все делать исключительно в XML, можно прекрасно обходится ДБФ, можно за эти два формата не знать ничего, а пользоваться исключительно ММО. Все можно. Но есть моменты, где только один из форматов окажется самым эффективным и простым решением. Да кстати, простой до безобразия пример: если мне надо разово из одной базы в другую скопировать два каких-то значения, то мне до свистка и XML, и ДБФ и все прочее - простой копипаст окажется самым эффективным. Или прикажешь XML городить?
Ответили: (156)
+ для 141 п2
Читай хотя бы посты не только свои - пост 124 пункт 3. Там Дбф обмена уже готовая база для составления заявки. И не надо ничего никуда загружать - работает сразу по получению.
Ответили: (156)
(141) fixin, Ок, продолжу дальше дискуссию, не знаю как у вас, но у меня зачастую обмены похожие, то есть то что я сделал одним клиентам может подойти и для других (нужно только сделать некоторые корректировки), так вот если я еще давно написал обработку обмена с помощью ДБФ и она уже проверена и успешно работает, то зачем мне для других клиентов переделывать обработку под ХМЛ? Или всё-таки нужно переделать что бы не быть неудачником?
Ответили: (156)
(134) fixin,
| Цитата |
|---|
| Гм, пора уже составлять список из тех, кто не вкурил фишку о том, что если работает - не менять. ;-) |
А как же не менять?
Как могла ТАМОЖНЯ не перейти на новый, современный формат XMLсо старого, устаревшего DBF?
Если бы таможня продолжала "юзать" DBF, она бы была "неудачником"!!!!!!!
(148) hogik,
Да, если еще больше обобщить мои слова,
то "старые" - это неудачники априори.
Даже мой 4-х летний сын это недавно осознал и расплакался: "не хочу стареть".
В данный момент времени он 4-х летний (молодой, красивый, здоровый, глупый), гораздо удачливее Вас, потому что есть большая вероятность что он проживет следующие 50 лет, а Ваша вероятность равна НУЛЮ.
Потому что у него все впереди, а у Вас все "было, было, было ...".
Ответили: (150)
(149)
Да. У него (и у всех) - всё впереди. В том числе и старость.
Какая разница - у кого, когда наступает это "было, было, было ...".
Оно у ВСЕХ наступает. Думаю, имеет значение "исторический" период времени куда "укладывается" наша жизнь. Возможно в этом и есть (не)удача. И это никак не связано с используемым форматом файла... :-)
Ответили: (151)
Понимаете дело в том что через 10 лет Вас на свалку и через 10 лет и Вы будете стариком. Но старый человек мудрее и в некоторых вещах где вы будете писать со своим xml и еще чем то он решит проблему проще объяснив что это не стоит тех денег и времени. А вы будете пиарить себя как всегда.
(142)(143) Вася, вы читать умеете. Я уже наверно в 10 раз повторяю то что написано в сабже - если DBF не задан постановкой задачи. Объясняю для Вас персонально еще раз - если что-то работает на DBF, смысла менять нет. Но если у вас выбор между DBF и XML и вы юзаете DBF - вы лузер. Почему, цепочку уже озвучивал, постарайтесь вкурить.
(144) вы читать умеете? Или хотя бы банально мыслить? Если у вас есть готовая тулза, юзайте на здоровье. Но если вы пишете новую тулзу/обработку и вместо XML юзаете DBF, вы лузер.
Ближайшая аналогия - 77 и 1с8. Если у вас есть заполненная база на 1с7, ее обычно нет смысла переводить на 1с8. Но если вы ставите новую базу клиенту, то даже если у вас есть полностью написанная конфа на 1с7, ее не имеет ставить клиенту, т.к. 77 - умирающий продукт. Лучше поставить 1с8, пусть даже ее придется дописывать клиенту. Уловили разницу, или разжевать, как гопо-Кушниру?
Теперь рассмотрим эту затравку , от которой закряхтели и отминусовались наши ветераны
(думаю , просто не поняли о чем здесь речь) :
| Цитата |
|---|
| Считаю, что в эпоху XML человек, который использует DBF для задач обмена, хранения данных или еще по каким-либо причинам, не связанным непосредственно с тем, что данные ему поставляются только в DBF - неудачник.
Пора выбросить этот формат на свалку истории в теме обмена. Я понимаю, что в 1С есть функции для работы с DBF, но использовать этот формат для обменов - маразм. |
Арчибальд "закряхтел" , что ,дескать, DBF для передачи накладных очень хорош и удобен :
DBF , по его мнению , удачно совмещает возможности хранения, передачи и просмотра и ,дескать, в этом его сила.
Никто не может запретить Арчибальду использовать DBF, дай Бог ему здоровья и 100 лет DBF-обмена в его конторе.
Задумается Арчибальд об XML , только тогда , когда его конфигурация будет обмениваться информацией с десятком других баз и для каждого обмена будет свой формат данных( не только DBF). Мыслишка об какой-то упорядоченности возникнет сама собой : а не сделать ли нам удобный универсальный формат прежде всего для обмена,
а хранение, просмотр и др. функции оставить другим форматам ?
Арчибальд, в этот момент(и не раньше) перечитай пост Фиксина и чего ты тут понаписал в(9),(97) и др.
| Цитата |
|---|
| А вообще, на физическом уровне любой файл обмена - это последовательность битов. Различие состоит в инструментах, которыми пользуется программист. А инструменты определяются (семантической) моделью данных. Эксимель неплох для небольшого дерева. Уже для двумерных массивов слишком расточителен. Ну, а когда появляются перекрестные ссылки он вполне может отдыхать. |
И вот "это вота" люди плюсуют...
Жуть. Даже аргументировать не буду.
Я обвиняю тебя в том , что "наукообразным" бредом ты смущаешь неокрепшие умы на ИС.
Ответили: (159)
В (68) перечислены недостатки XML и в конце эффектный вопрос :
| Цитата |
|---|
| Вопрос: как назвать человека, работающего с форматом с ТАКИМ количеством недостатков? |
| Цитата |
|---|
| Вы мыслите рельсом .(с) Штирлиц |
Почему же (68) - это "рельс" ?
Потому что все форматы обладают недостатками ( И распространенные , и "не очень", и даже DBF).
Дело не в них.
А дело в преимуществах того или иного формата.
Причина чрезвычайно широкого распространения XML - в его универсальности.
Возможность использовать для обмена между любыми информационными базами один признанный всеми формат
перекрывает любые его недостатки.
Разжевывать дальше - стесняюсь.
Игорь с фиксом освоили новую "продвинутую 1сом" профессию - 'программист XML'
Еще немного, и они расскажут нам о хмл-обмене номенклатурой с картинками.
С другой стороны, смущает, что они прикрываются термином 'XML', умалчивая, что освоили только 1сную реализацию этого формата. Как они собираются обмениваться, например, с Парусом, Аксаптой - вот бы рассказали о своем, несомненно - высокопрофессиональном, опыте.
(155)
"как закряхтели наши ветераны"(с)
Игорь.
Позволю себе, без разрешения автора, привести цитату:
"Нет, тема автора не об этом. Она вообще не относится к обмену данными/хранению данных..."(с)
Автор темы угрюмо обсуждает особенности форматов файлов.
А его призывают перестать гадить в общественных местах...
Ответили: (175)
проверено:
стояла задача ... выгрузить данные ... загрузить данные ... формат файла обмена xml ...
основная проблема:
есть два документа ... в каждом есть номенклатура ... есть и одинаковая ... так как решать выгружен (загружен)элемент или нет?
1 вариант: xpath ... скорость ... даже не говорю
2 вариант: СписокЗначений ... быстрее. при маленьком объеме годиться ... больше десяти тысяч ... лучше не надо
...
выбрал вариант: временная таблица dbf с полями: внутренне представление объета (уникальный индекс: при попытке вставить запись с таким же ключом ошибка быстрее работает чем поиск) и memo (узел xml)
(правда использовал ado vfpoledb и временную таблицу в памяти)
скорость рабочая ... даже при условии что при загрузке сначала xml файл загружал в dbf а потом уже обрабатывался
(154)
Спасибо за ссылки. Интересный материал.
А ещё в старости появляется замечательное качество - склероз.
Вот, никак не могу вспомнить в своей молодой жизни подобных обсуждений формата файла.
Видимо форматов было мало и не приходилось обсуждать так долго подобную мелочь.
Не помню... И это радует...
(166),(167) Ты , Миша , явно на какой-то своей волне. В XML - я дилетант и разминаюсь здесь из спортивного интереса.
(168) Отношусь к полемическому задору Фиксина очень спокойно,
т.е. как к приему , обеспечивающему нужный градус дискуссии.
Сам фильтрую и Вам советую.
Возражения же по содержательной части поста Фиксина читать просто грустно:
пара описаний , вот, дескать, был такой случай ,что DBF -то покруче будет.
Ликбез читать не буду , предлагаю каждому самому ответить на вопросы :
1. Что такое универсальность и почему так популярен XML ?
2. Откуда он взялся , и почему широкое распространение получил последние 5,6 лет ?
(167) Я думаю в xml это возможно - двоичные форматы преобразуются в base64 строку, - это конечно, отстой для производительности, но плата за универсальность.
(175) У него в утверждении ошибочно выделенная часть
| Цитата |
|---|
| DBF для задач обмена, хранения данных или еще по каким-либо причинам, не связанным непосредственно с тем, что данные ему поставляются только в DBF - неудачник. |
Ну ладно, фиг с ним с форматом. Я так чисто поразмышлять. Вот есть два вида обмена - регулярный(те же РИБ-ы) и нерегулярный(условно так назвал, имеется ввиду непериодический обмен и необязательно 1С с 1С). Для второго случая, конечно, в общем случае лучше, но главное универсальнее, чем xml вряд ли получится. Рассмотрим 1 вариант. Что представляет из себя распределенная база пускай хоть и из обычных нормализованных реляционных подбаз, - по сути это одна нереляционная база. Мне видится, что для обмена - одного xml здесь маловато. Т.е. для обмена теоретически неплохо бы смотрелся прикрученный движок какой-нибудь nosql базы - наподобие Couchdb, у которой механизм синхронизации данных встроен (собственно для это её и используют), с помощью какого формата по сути происходил бы обмен , неважно (xml или json например). Суть в том, что рассматривать распределенную базу именно как единую нереляционную базу, а обмен между узлами и рассматривать как просто поведение/перенос объектов в рамках этой базы . Как-то так.
(176) cool.vlad4, какой такой пук. Ты вообще думаешь, о чем пишешь? Ты пишешь, что в 77 использовался DBF, но он использовался для хранения базы данных, а XML в РИБ используется для ОБМЕНОВ ДАННЫМИ. Две разные вещи! Это осознанная демагогия или глупость от неумения дифференцировать?
Бред про нереляционные таблицы комментировать не вижу смысла.
Ответили: (178)
(177) слушай фильтруй базар, ты человек известный, со всеми вытекающими.
| Цитата |
|---|
| Ты пишешь, что в 77 использовался DBF, но он использовался для хранения базы данных, а XML в РИБ используется для ОБМЕНОВ ДАННЫМИ. Две разные вещи! Это осознанная демагогия или глупость от неумения дифференцировать? |
| Цитата |
|---|
| DBF для задач обмена, хранения данных или еще по каким-либо причинам, не связанным непосредственно с тем, что данные ему поставляются только в DBF - неудачник. |
| Цитата |
|---|
| Бред про нереляционные таблицы комментировать не вижу смысла. |
Ответили: (180)
(180) Это к чему? Если не быть буквоедом, можно долго и долго спорить, а потом кое-кто скажет, ну так блин я это и имел ввиду. СУБД - (сохраняя твою дурацкую формулировку) это не только хранение. Если ты это сказал в контексте xml - то она-то как раз и не хранение данных, это язык самоописания данных(ну поскольку метаданные в данных), поэтому может храниться в другой базе, например в ms sql. Если ты это в контексте 176, то откуда ты знаешь в общем случае как одна база с неизвестной тебе структурой относится к другой с тоже неизвестной структурой? Если прочесть внимательно, то выяснится, что нереляционную схему я предлагал для хранения данных для обмена. В других системах(не 1С) этот механизм используют, когда не могут сделать свой механизм реплик/обмена(на одной из конференций случай реального применения приводился, сейчас ссылку вряд ли найду). И повторюсь умерь своё высокомерие.
Ответили: (187)
(175)
Игорь.
Я воспользовался Вашим советом. Перечитал тему. Отфильтровал. Вроде, всё понял.
Автор темы задал простой вопрос: "DBF юзают неудачники?"(с)
Видимо его заставляют их "юзать" и он опасается стать неудачником.
Автор темы хотел простого человеческого успокоения, участия и сострадания. А мы тут развели обсуждение (осуждение). Наехали на человека. Лично я, прошу прощения у автора.
Мой ответ автору темы: "Нет. Можете "юзать" спокойно.".
(175) Ish_2,
| Цитата |
|---|
| предлагаю каждому самому ответить на вопросы :
1. Что такое универсальность и почему так популярен XML ? 2. Откуда он взялся , и почему широкое распространение получил последние 5,6 лет ? |
Для себя я ответила на эти вопросы в посте 112:
Дон Петерсон в статье "Является ли XML панацеей?" четко сформулировал:
"1. Незнание. Отделы маркетинга управляют разработкой продукта и очень хотят, чтобы он содержал какойнибудь модный термин. Незнание частью общества потребителей реального положения вещей позволяет маркетологам увлечь нас разговорами.
2. Глупость. Технические «эксперты» часто неграмотны, и, так как этому нет никаких оправданий, я назову это глупостью....
3. Жадность. ... XML «улучшит» .... благосостояния поставщиков программного и аппаратного обеспечения"
А потом в посте 133 привела пример нашей российской таможни, который полностью это подтверждает:
Введя в 2004 новую ГТД они решили внедрять её на новом, современном формате... а дальше- все как в статье 112. И компьютеры, и софт им пришлось обновить, и все сроки они затянули, не успели..., и ошибки много лет (и в 2011 г) - лезут и лезут, и форматы они до сих пор меняют и меняют каждый месяц.... никак не могут приспособиться....
P.S.
Что, тоже балуешься? :))
Ответили: (192)
Так что я лично (если это не будет жестко заданно) не буду использовать xml для обмена с другими. Слишком тяжело договариваться о формате, слишком сложно проверить структуру выгруженных данных.
А имея dbf файл с чужими данными - мне вообще ничего объяснять не надо. Чтобы разобраться со структурой данных одного взгляда достаточно.
(181) Влад, разжую для буквоедов специально. Преимущество DBF в том, что этот формат годен для хранения данных в СУБД и быстрого индексированного поиска. Но это нафиг не надо в задачах обмена. 80% случаев, когда 1сники юзали DBF - для обмена. Вот об этих задачах я и твержу. Хватит юзать DBF для обмена, хватит быть лузерами. Давай не витать в облаках, а говорить о практических задачах.
(182) не фрейдируй со своими домыслами.
(185) ха, а по XML нельзя догадаться о формате? Ну это вообще лузерство - открой XML в нотпаде или XML SPY и структура налицо. И потом - что это за привычка делать обмены без описания спецификаций? Тоже лузерство и низкобюджетное ремесленичество.
(186) я не просто сказал, а объяснил, почему DBF сложнее. Ищите в ветках. Надоело жевать одно и то же.
Вот думаю, может создать краткое резюме этой темы, чтобы тыкать в него носом тех, кто не умеет читать.
(145) + (166)
я тут подумал, на самом деле ваш пример с 53-м работает в другую сторону -
и микроужастик "гонения на фикса", и наблюдаемые макроужасы имеют одну природу:
кто-то как-то получил какую-то власть и полагает, что эта власть - его свойство (привилегия, право), а не функция (обязанность, ответственность)
такой подход логичен в случае оккупации, и работает в "макроэкономике", пока не вымерло население или не кончилась нефть.
но в случае более-менее рынка нет ни закона о всеобщей повинности, ни природной ренты, потому применение пенитенциарной системы себя не оправдывает и объявляется "амнистия"
(187) "хранения данных в СУБД и быстрого индексированного поиска. Но это нафиг не надо в задачах обмена."
что же такое обмен?
1. сохранить данные в какой-то структуре
2. транспортировать - здесь имеем доп.расходы на сжатие рыхлого хмл
3. сравнить с тем, что уже есть и по каким-то правилам обработать/записать == поиск
4. для передачи типа "картинок" - доп.расходы на преобразование(+обратное) в текстовое представление
"XML — документ с иерархической структурой, что дает возможность обработки документа: трансформацию данных, поиск нужных элементов документа" - угадайте, откуда я взял эту цитату?
если говорить о практических задачах, то когда вынужден иметь дело с (частью) типовой 1сной схемой обмена - хмл воленс-неволенс. но если обмен целиком твой, ты сам составляешь структуру обмена - хмл становится последним прибежищем патриота 1с.
"открой XML в нотпаде или XML SPY и структура налицо"
автор явно не открывал хмл размером более, чем умещается на одном экране - только в этом случае структура хмл "на лицо"
"что это за привычка делать обмены без описания спецификаций? Тоже лузерство и низкобюджетное ремесленичество."
гы-гы-гы... автор, узнай: отсутствие необходимости "договариваться" о спецификации - основное и, быть может, единственное основание появления формата типа хмл.
на самом деле это основная проблема таблиц типа ДБФ - отсутствие описания содержания колонок на предметном уровне.
"почему DBF сложнее"
дерево сложнее таблицы? или таблица сложнее дерева? фигня какая-то
но, если мы в файл впихиваем не только данные, но и их описание, файл сложнее по определению
"может создать краткое резюме этой темы"
попкорну мне, попкорну! и пива
(190) по пункту 3 - поиск не в DBF/XML, а в базе, в которую идет загрузка. Облажался ты...
И часто ты передаешь двоичные данные типо картинок в 1C
по пункту 2 - Про fast infoset автор не слыхал, про то, что сжатие - это 1% времени выгрузки, автор тоже не знает...
Дальнейшее такой же бред, лень комментить, уже отвечал
(182),(183) Друзья, я, кажется , понял в чём дело. Это трудности фильтрования.
К вам подходит Фиксин и говорит :
"Ты - неудачник. Хочешь узнать почему ?"
Хм.. с такой стартовой позиции начинать конструктивную беседу решится не каждый.
Ответы "сам козёл" и "а пошел ты " - обычное дело.
Придется показать на личном примере.
Дело в том , что я -неудачник. Я работаю с DBF .
(Читать здесь описания преимуществ работы с DBF без усмешки просто невозможно).
Перестану я работать с DBF , после темы Фиксина ? - НЕТ.
Но я понимаю правоту Фиксина , т.е необходимость перехода к XML, как универсальному языку обмена.
И отдельно про универсальность языка обмена.
Когда говорят об обмене, то по-житейски подразумевают что и источник, и приемник обмена известны и определены. Так вот. Допустимо ли говорить об обмене если приемник неизвестен ? - Да , допустимо !
Но только тогда , когда существует универсальный формат обмена (XML).
Действительно , вы разработали некоторую конфигурацию и должны предусмотреть средства интеграции.
Вопрос : Куда будем выгружать ? в какие информационые базы ?
Ответ : В любые ! У нас есть XML-формат для выгрузки.
Этот формат может быть прочитан в любой другой ИБ.
В этом сила XML (она же , разумеется, и слабость).
(187) fixin,
В любом случае спасибо за создание этой темы.
Ваши едкие, не аргументированные реплики меня мало волнуют.
А вот умных статей на тему применения xml прочитала благодаря Вашей теме массу.
Например:
на тему "Когда использовать XML, а когда использовать реляционный формат данных"
Здесь все разложено по полочкам:
[/"Вообще, реляционная структура - часто правильный выбор, если для ваших данных истинно один или несколько следующих утверждений:
- Данные естественным образом отображаются в табличный формат.
- Данные будут впоследствии обрабатываться совместно с другими реляционными данными или реляционными приложениями.
- Вам необходима высокая производительность в обработке данных. XML-данные потребляют дополнительное процессорное время для разбора и интерпретации XML.
- Ваши данные имеют значения, которые независимы от иерархии XML, которая описывается родительско-дочерними отношениями.
Точно так для вас может быть лучшим хранение данных в XML, комбинируя их с реляционными данными, если для ваших данных истинно один или несколько следующих утверждений:
- Данные естественным образом отображаются в иерархический формат. Это противоположно данным, которые отображаются в табличном виде и удобно хранятся в реляционной базе данных. Иерархические данных может быть трудно отобразить на реляционную схему. Объединение SQL и XQuery позволяет вам оперировать с данными, которые хранятся и в реляционных таблицах, и в XML, в одном запросе.
- Схема часто трансформируется. Изменение бизнес-процессов, внедрение новых услуг или товаров или правительственные руководящие указания часто требуют обработки новых или других элементов. Поскольку XML схемы гибкие, вы можете посчитать практичным хранение XML-документы в их естественном формате вместе с существующими реляционными данными, чтобы избежать сложностей, которые могут возникнуть из-за частых изменений реляционной схемы.
- Преобразование схемы в общем случае легче осуществляется в XML, чем в реляционном формате. Некоторые реляционные изменения схемы просты, например, добавление колонки. Однако, некоторые довольно сложны, например, нормализация таблицы в несколько таблиц. В сложных случаях, вы можете сэкономить много времени и усилий, храня изменчивую часть данных в колонке типа XML.
- Данные имеют существенное количество атрибутов, редко имеющих значения. Такие атрибуты преобразуются в пустые ячейки в реляционной таблице. Поиск данных или другая аналитика в реляционных таблицах, которые содержат пустые ячейки, могут давать недостоверные или ошибочные результаты. Хранение данных в формате XML может помочь предотвратить такие ошибки. Некоторые приложения постоянно производят такие атрибуты, значения которых пусты или не определены. Данные часто содержат такие атрибуты, когда существует большое количество возможных атрибутов.
- Компоненты объекта имеют смысл в контексте только данного объекта. То есть, компоненты принадлежат объекту. Опасность заключается в нормализации данных до такой степени, что вам приходится соединять многочисленные столбцы при выполнении каждого запроса.
- Данные, небольших размеров, часто в высокой степени структурированы и могут быть критичными для бизнес-приложений. Однако, когда вы нормализуете данные небольших размеров, вы можете легко прийти к громоздким реляционным схемами, которые требуют сложного управления базой данных. "
Для себя я сделала вывод:
И дальше использовать DBF, если данные естественным образом отображаются в табличный формат.
Еще раз спасибо
Ответили: (195) (196) (197) (198) (199) (200) (201) (202) (204)
(192) "Вопрос : Куда будем выгружать ? в какие информационые базы ?
Ответ : В любые ! У нас есть XML-формат для выгрузки."
садись два, Игорек.
знай: есть такая шняга, как "правила обмена"
и без этой шняги супер-разрекламированный хмл не может ничего. совсем ничего.
Что же это за зверь?
А это и есть пресловутая спецификация.
Т.е 1с вполне могла бы сделать "ковертацию данных" под ДБФ и создавать правила конвертации (спецификацию) для этого формата. Почему не сделала? Ну, тут уже отвечали: в основном - маркетинг, модно, "прогрессивно", "современно", etc
То есть, лажанувшись (и лажанув в последствии фикса) на рекламе хмл, как формате универсальном за счет содержания спецификации внутри себя, 1сина выносит мозг практикующим 1снегам конфигурацией "Конвертация данных", без которой использование этого формата в 1с невозможно.
(193) спасибо, Марго
на самом деле эти пункты в 1с применить "в лоб" трудно потому, что ни одна (типовая) конфигурация 1С ни разу не нормализована. т.е. применять какие-либо критерии теории баз данных к (типовым) базам данных 1С вообще нельзя - без оговорок. Оговорки же в большинстве случаев по объему превысят своих родителей - критерии "нормальных" баз
+(193)
"- Ваши данные имеют значения, которые независимы от иерархии XML, которая описывается родительско-дочерними отношениями."
ну, это раз. стандартные грабли 1с-хмл по этому пункту - наличие в приемнике записей регистров сведений с пришедшим набором измерений. коврик сворачивается на уровне платформы, совершенно забывая об "универсальности формата".
+(193) "Опасность заключается в нормализации данных до такой степени, что вам приходится соединять многочисленные столбцы при выполнении каждого запроса."
улыбнуло. опасность "соединять многочисленные столбцы при выполнении каждого запроса" в 1ске действительно есть, но отнюдь не из-за излишней нормализации :)
и как это притянуть к "преимуществам" хмл?
Танго, что за бред ты несешь про конвертацию данных?
При чем тут DBF & XML.
ЕЩе раз для двоечников - у XML можно передавать в одном файле много таблиц и он текстовый формат (т.е. не требует двоичного чтения через специальное API).
Поэтому XML так популярен для обменов.
DBF для обменов используют лузеры.
Даже когда передаешь исключительно табличные данные, не мешало бы передать спецификацию данных - дату выгрузки, размер пакета и т.п.. Тут XML на высоте - просто добавляешь нужные секции (ну я об этом уже писал).
Говорить о преимуществах DBF могут только лузеры. Не увидел еще ни одного объективного аргумента.
+(193) "- Данные, небольших размеров, часто в высокой степени структурированы и могут быть критичными для бизнес-приложений. Однако, когда вы нормализуете данные небольших размеров, вы можете легко прийти к громоздким реляционным схемами, которые требуют сложного управления базой данных."
эта пять. даже если поверить, что автор (цитаты) понимает, что сказал, это не имеет никакого отношения ни к базам на платформе 1с, ни к реализации хмл-формата в 1с.
(195) "Видимо потому, что с DBF в PHP Траблы."
нет фикс, не поэтому
попробуй как-нибудь, на досуге, перегнать таблицу значений между клиентом и сервером в "управляемой форме"
что-то не спешит флагман заюзать для этого ни хмл, ни комма сепарейтид (шутка)
(195) fixin,
| Цитата |
|---|
| слышал ты звон, да не слышал где он.
Если у тебя обмен табличными данными, лучше использовать CSV, а не DBF. |
Это типа шутка или правда так считаете?
:))))))
Значения в строке чем разделять будешь? Запятыми?
А как отличать будешь запятую разделитель от запятой в данных?
:))))
У меня в практике не встречались ситуации, в которых я отдала бы предпочтение этому формату.
Хотя, конечно, и от использования этого формата я не зарекаюсь.
Ответили: (212)
(206) обмен данными между клиентом и сервером - это типовая задача обмена, решаемая 1сниками? Это задача реализации платформы, а не обмена. Вы еще не устали от своей демагогии?
(208) это те проблемы, которые действительно вас волнуют? Про экранирование спецсимволов вы ничего не знаете? Ваш уровень налицо, мне даже комментировать не нужно.
(209) именно. Потому текстовый формат XML и стал универсальным, т.к. не требует спец. подпрограмм и драйверов. С текстовыми файлами даже 1с умеет работать.
(210) меня побудил совет одного из коллег на инфостарте "ну обменяйся там через текстовые файлы или DBF". Советовать писать через DBF в 2012 году - меня это поразило до глубины души. Я не назвал товарища лузером, но решил открыть просветительскую ветку.
(211) не надо софистики. Человек пользующийся отверткой, когда у него в шкафу пылится шуруповерт вызывает сочуствие и человеческое желание помочь ему, неразумному.
| Цитата |
|---|
| "Вопрос : Куда будем выгружать ? в какие информационые базы ?
Ответ : В любые ! У нас есть XML-формат для выгрузки." садись два, Игорек. знай: есть такая шняга, как "правила обмена" и без этой шняги супер-разрекламированный хмл не может ничего. совсем ничего. Что же это за зверь? А это и есть пресловутая спецификация. |
Не горячись, Миша. Сейчас ты всё поймёшь.
"Правила обмена" - это набор инструкций для интеграции ,
устанвливающий соответствия между данными двух конкретных информационных баз (источника и приемника).
"Правила обмена" имеют смысл только тогда, когда определены и источник , и приёмник в обмене.
Теперь я тебе говорю :
Выгрузи-ка , Миша, мне все расходные накладные за период.
Ты мне :
Куда загружать будем ?
Я тебе :
А черт его знает. Ты выгрузи , а там посмотрим.
Итак , задан источник , но не задан приемник. "Правила обмена " - тут ни при чём.
Но ты же , Миша, - парень ушлый и грамотный ,тебя так просто не проймёшь.
И ты делаешь :
1. Формируешь файл XML-схему , в котором описываешь структуру данных (на твоем жаргоне -"спецификацию")
для облегчения парсинга на стороне неизвестного приемника.
2. Формируешь сам XML-файл , в котором содержатся данные накладных.
Теперь данные готовы для загрузки в любую ИБ.
Ответили: (218)
(212) "обмен данными между клиентом и сервером - это типовая задача обмена, решаемая 1сниками?"
я не был уверен, что ты не поверишь :)
погукли "1С управляемая форма" :)
"формат XML и стал универсальным"
ну, т.е сначала он как бы не был универсальным. потом стал текстовым - и это ему помогло завоевать просторы :)
еще, пожалуйста :)
(213) нет, дорогуша.
между первой и второй есть перерывчик
1. как ты и пишешь
2. загружаешь "файл XML-схему" в КД
3. повторяешь 1. для базы приемника
4. повторяешь 2. для базы приемника
5. выносишь себе моск, получаешь "правила конвертации"
6. загружаешь правила еще в одну шнягу (что-то опять "универсальное" - в рамках и понятиях 1с, разумеется), и только тут получаешь выгрузку, которая может быть загружена только в базу-приемник, никак не в любую
понятно объяснил?
Ответили: (223)
(219) Тут интрига местного значения. Фикс с какого-то бодуна начал воспевать явно корявое решение 1сы по обмену. Причем прёт буром, не опасаясь в неокрепших умах выглядеть слегка неадекватным, с порога объявляет себя в белом, остальных - всех! - известно в чем.
Интрига: с какого именно бодуна?
(218) Миша , как же отштампованы у тебя мозги "правилами обмена" и конфигурацией "Конвертация данных".
Я тебе толкую : в нащем обмене приёмник НЕИЗВЕСТЕН - он может быть и не 1с вовсе !
Забудь свои "правила обмена" - они здесь не нужны ! Не нужна и конфигурация "конвертация данных".
Еще раз :
Стоит задача выгрузить данные накладных . Приёмник обмена неизвестен. Точка.
Для этой задачи и хорош XML.
Мы вначале описываем в XML-схеме структуру выгружаемых данных (декларируем).
Затем создаем XML-файл содержащий сами данные . И всё.
Загрузка этого файла - не наше дело. ,потому что мы не знаем куда грузить.Понимаешь ?
А тот, кто будет грузить пусть анализирует XML-схему и определяет свои правила загрузки.
Эти правила загрузки могут быть разными для разных ИБ. Чуешь ?
Вот чем хорош универсальный язык обмена XML !
Ответили: (225) (260) (328) (329)
(223) "А тот, кто будет грузить пусть анализирует"
Игорь, есть еще более универсальная схема. Отдай принимающей стороне копию базы - пусть анализирует и загружает себе, чего надо.
Но какое отношение имеют твоя и моя схема к реализации обмена в 1с? никакого, собственно, кроме надувания щек: ах какие мы передовые! у нас хмл!
Понял! слушайте, слушайте! эпатаж фикса - это просто пародия.
(212) fixin,
| Цитата |
|---|
| это те проблемы, которые действительно вас волнуют? Про экранирование спецсимволов вы ничего не знаете? Ваш уровень налицо, мне даже комментировать не нужно. |
Ок, я то сразу поняла, то у нас диалог между умным и грамотным человеком.
А экранированием заниматься надо и при экспорте, и при импорте.
Тем, кто любит трудности и не ищет простых путей, это понравится. :-)
Считаю, что в эпоху XML человек, который использует DBF для задач обмена, хранения данных или еще по каким-либо причинам, не связанным непосредственно с тем, что данные ему поставляются только в DBF - неудачник.
Пора выбросить этот формат на свалку истории в теме обмена.
Я понимаю, что в 1С есть функции для работы с DBF, но использовать этот формат для обменов - маразм.