Поддерживает.. Что за глупое выражение

← →
Медвежонок Пятачок © (2009-04-10 09:10) [80]

так как в гомогенной среде вопрос об формате данных не стоит, а стоит вопрос об их удобном представлении для обработки (бинарный вид).

удобное проедставление в том числе для удобной обработки очень хорошо вяжется с xml

← →
Rouse_ © (2009-04-10 09:17) [81]

ХМL очень удобная чтука, особенно когда отбрыкиваешся от клиентов которые хотят чтобы мы за собственные деньги состыковали выходные данные нашего ПО с ихними программными комплексами :)

ХML получили? Описание его получили? Вот и... "занимайтесь с ним любовью" :)

← →
Медвежонок Пятачок © (2009-04-10 09:19) [82]

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

← →
Медвежонок Пятачок © (2009-04-10 09:20) [83]

последний пост - это про "ненужность" xml в гомогенной среде.

← →
sniknik © (2009-04-10 09:36) [84]

> Что, и при передаче бэкапов баз mssql вынуждают XML применять ?
нет слава богу, но один раз с подачи менеджера таки в нем прислали... была проблема его создать на той стороне, у меня принять (если бы "повелся" и стал с ним работать), и главное то как его создали, не подразумевало нужных мне данных о структуре... но тем не менее мои слова "это не подходит" почему то тоже восприняли также как в этой ветке, как будто я сказал "не умею его читать/с ним работать"... и неделю "уламывали" сделать из него то что нужно, пойти "вот на тот сайт там есть парсер который сможет прочитать такой xml" и т.д. (ко всему прочему он еще стандартным мелкософтским объектом не открывался из-за размера)
эту "страшную" историю я на этом уже пару раз рассказывал.
и кстати если бы я тогда это принял... страшно подумать что могло бы быть. при общей такой любви к нему у менеджеров.

> причины:
> 1. .....
> 2. .....
аааааа...., это ты о чем? кто мне не даст в своем приложении? при чем тут безопасность. аааааа... извини но я устал читать твою чушь. проще наверное игнорировать.

> Не умеете вы говорить с менеджерами. Хоть бы книжки почитали.
а с чего это я должен учится с ними говорить? и тем более красиво им чтото расписывать?
я один, а их много, и постоянно меняются. если буду каждому расписывать работать не когда будет. а так, у меня еще и свободное время есть.

> А в случае с XML они и сами проверят валидность и супротив стандарта не попрешь.
в случае обмена таблицами (тем же dbf. который предлагался, в отличие от самопального на который просто был ответ из-за сравнений с ним) тоже есть проверка валидности, и числа туда нормально попадают читаются движок заботится. и... ???
вот у нас 1C-совцы, обменивались dbf-ами (другим не могли) и были счастливы, после пришла 8-ка, и тут же "нам нужен xml", ну им там просто (огда механизм предоставили), нужно сделали, и скорость обмена (приема данных) упала в 3 раза. сказали "фигня, зато поддержка модного формата, а обмен должен делаться маленькими порциями, не заметно". но только "тупые" юзеры нифига не понимают, видят "выгрузка" и жмут выгрузить весь справочник т.к. на новую установку им его весь необходим. а там в зависимости от размера скорость падает по экспоненте, до полного ступора... ладно, сделали ограничители количества (то ли 5 то ли 50 тыс, а обычно справочник товаров = 80-130 тыс), теперь справочники переносят кусками... и все "счастливы", ну кроме тех юзеров, что помнят насколько проще было с dbf. и кому это было нужно? если и так все работало.
а счас на "подходе", планируется 3-е изменение, суть так и делить на куски но скрыто от юзера, паковать куски и давать ему зип архив, чтобы одним файлом, на другой стороне обратные действия...
и никто не хочет признать, что его внедрение только добавило проблем, откатится на старое и все. нет, т.к. это первое потеря "модного формата" нельзя будет говорить, что поддерживаем, признание, что были идиотами когда не слушали техников (про "ситуацию" предупреждали заранее), ну и они постоянно "решают проблемы по мере поступления", допускаю что просто не помнят о чемто другом кроме того что перед носом, отсюда и такие неуклюжие, громоздкие решения.
да и насчет очевидного "а дайте им выбор xml/dbf", нельзя, юзер он же "тупой", не нужно ему давать ветвления для однозначных действий, это его сбивает. (слова начальства, и вот кстати тут, я его поддерживаю, ибо разумно).

> Выдача - в xml. Больше у него вопросов не было.
а если бы была таблицами, возникли бы? думаю нет (проверь, скажи что хочешь поменять, оставив содержимое по полям тем же самым. будут вопросы типа, а как читать dbf?... ;)), я уже писал, что по моим наблюдениям "техники"(/программисты) мало внимания уделяют внешнему формату, больше содержанию. а понимать "обертку" могут как правило все (ну, либо мне везло). а если не могут в данный момент то быстро учатся.

← →
Медвежонок Пятачок © (2009-04-10 09:44) [85]

в случае обмена таблицами (тем же dbf.

с ним далеко не все в шоколаде.

← →
Игорь Шевченко © (2009-04-10 11:27) [86]

sniknik © (10.04.09 09:36) [84]

Формат не только модный, но еще и удобный. Впрочем, никто не запрещает обмениваться и dbf и бэкапами баз mssql, просто это не недостаток XML, что "юзеры жмут выгрузить все"...

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [87]

> sniknik (09.04.2009 23:38:30) [30]

И проблемы, как минимум по ресурсам.
Я уже расказывал, но еще раз повторю, как мы переносили базу с dbf на MS SQL.
Сначала по рекомендации запустили экспорт в формате XML, спустя неделю аварийно сняли процесс, надоело ждать, по оценке, за это время, было выполнено всего 30%.
Затем запустили не рекомендованый путь, через DBF - спустя 1.5 часа наслаждались результатом.
Прямо перегонять с помощью запросов нельзя, множество преобразований и проверок, иначе бы всего несколько INSERT INTO.

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [88]

> Хитрий Лис (10.04.2009 0:19:35) [35]

Вот когда кормить будут, тогда да, но пока насилуют.E5ще раз повторю, как мы переносили базу с dbf на MS SQL.
Сначала по рекомендации запустили экспорт в формате XML, спустя неделю аварийно сняли процесс, надоело ждать, по оценке, за это время, было выполнено всего 30%.
Затем запустили не рекомендованый путь, через DBF - спустя 1.5 часа наслаждались результатом.
Прямо перегонять с помощью запросов нельзя, множество преобразований и проверок, иначе бы всего несколько INSERT INTO.

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [89]

> oxffff (10.04.2009 0:24:36) [36]

Скажем между DBF и XML по этой части практически нет никакой разницы, кроме огромного оверхеда и плюса при передаче по сетям - текстовый формат, не надо упаковывать и/или передавать как вложение, в случае почты, но это плюс призрачный. Это по формату, а по времени обработки и ресурсам смотри предыдущее сообщение.0через DBF - спустя 1.5 часа наслаждались результатом.
Прямо перегонять с помощью запросов нельзя, множество преобразований и проверок, иначе бы всего несколько INSERT INTO.

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [90]

> oxffff (10.04.2009 0:56:42) [42]

> Сложность в том, что значения полей подразумеваются быть на данном месте по определенному абсолютному или относительному смещению от начала файла.

Для баз данных это не так, только начинающие или недостаточно квалифицированые работники опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

XML удобен для иерархических данных, например меню, файловые системы и подобное. Для реляционых баз просто потеря времени, ресурсов, сложность обработки.

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [91]

> sniknik (10.04.2009 1:26:52) [52]

Очень нравится, когда ни с того ни с сего госорган присылают отчет в виде XML файла и пользователи думают что же с этой абракадаброй делать, а открывается он в Экселе. Никакой поддержки от госоргана получено не было. Звонить также бессмысленно.опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

XML удобен для иерархических данных, например меню, файловые системы и подобное. Для реляционых баз просто потеря времени, ресурсов, сложность обработки.

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [92]

> Игорь Шевченко (10.04.2009 2:29:12) [72]

Игорь так тема то о том, об универсальности и применяемости везде. С этого начиналось, это и развенчивается, что не надо применять всегда и везде. И что область применения много меньше.E0 получено не было. Звонить также бессмысленно.опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

XML удобен для иерархических данных, например меню, файловые системы и подобное. Для реляционых баз просто потеря времени, ресурсов, сложность обработки.

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [93]

> sniknik (10.04.2009 2:34:14) [74]

Если бы только поставить галочку.2ом, об универсальности и применяемости везде. С этого начиналось, это и развенчивается, что не надо применять всегда и везде. И что область применения много меньше.E0 получено не было. Звонить также бессмысленно.опираются на или относительному смещению от начала файла. Остальные работают с именами или метаданными. Перенос через XML ничто иное как перекодирование в текстовый вид и данных и метаданных. Нет преимуществ, куча недостатков.

XML удобен для иерархических данных, например меню, файловые системы и подобное. Для реляционых баз просто потеря времени, ресурсов, сложность обработки.

← →
Anatoly Podgoretsky © (2009-04-10 12:04) [94]

> Rouse_ (10.04.2009 9:17:21) [81]

> ХML получили? Описание его получили? Вот и... "занимайтесь с ним любовью" :)

Правильнее так

ХML получили? Вот и... "занимайтесь с ним любовью" :)

Он же самодокументированый :-)

И именно с такими ситуациями я и сталкивался в основном, и при том с обязательностью обработки, иначе до 7 лет.
Ну ладно я справлюсь, а что делать рядовым пользователям?
При наличии только таких средств как Эксель, ИЕ2ид и данных и метаданных. Нет преимуществ, куча недостатков.

XML удобен для иерархических данных, например меню, файловые системы и подобное. Для реляционых баз просто потеря времени, ресурсов, сложность обработки.

← →
app © (2009-04-10 12:05) [95]

> oxffff (10.04.2009 1:18:49) [49]

Давай без наездов, сдерживайся. А то ты уже несколько раз подряд успел оскорбить на ровном месте.
Тоже к остальным участникам.

← →
app © (2009-04-10 12:05) [96]

Удалено модератором

← →
sniknik © (2009-04-10 12:32) [97]

> но еще и удобный.
вот в упор не вижу удобности, с данными удобно работать в "естественном" формате, в том в котором они есть, теми средствами которые для этого предназначены. остальное только лишняя морока. (и да, программист может не знать этих средств... но это уже проблема другого плана)

Anatoly Podgoretsky © (10.04.09 12:04) [87]
фух, ну хоть еще один понимающий, гора с плеч... я уж начинал думать, что я один такой. :))

кто сталкивался с проблемами только тот видать и понимает. остальные "прячутся" за маркетинговые сказки об универсальности/удобности/что можно не думать т.к. формат готовый (а содержимое? вот пришёл хмль в нем тег "число = 3" и что с этим делать?) и т.д..

> XML удобен для иерархических данных, например меню, файловые системы и подобное.
:) а "сторонники", почему то ни одного примера нормального выдать не могли, только обещали, кроме того, что им удобно настройки иерархические хранить...

да, этим пользуюсь, по сути (не xml-ем), в мазиле список закладок экспортируется/принимается в xml, но там же есть и json (и 100% тех же возможностей) и опять, а какая разница? почему про xml сказки об универсальности есть, а json просто еще один формат, не лучше не хуже других?
выбираю json, т.к. он меньше размером получается, хотя при нынешних винтах это вроде и не должно на выбор влиять. но если не видно разницы в остальном ... ? и если бы нужно было подобное передать, то тоже бы постарался им (если другая сторона будет не против).

← →
DVM © (2009-04-10 12:43) [98]

> sniknik © (10.04.09 12:32) [97]

> фух, ну хоть еще один понимающий, гора с плеч... я уж начинал
> думать, что я один такой. :))

Не один :) Мы с тобой! :)

← →
Palladin © (2009-04-10 12:45) [99]

> sniknik © (10.04.09 12:32) [97]
> фух, ну хоть еще один понимающий, гора с плеч...

Ну почему один. Я тоже понимающий. Просто, молчу сижу... :)

← →
Медвежонок Пятачок © (2009-04-10 12:54) [100]

кусок примочки к одному популярному авиасимулятору
http://il2sc-cherep.narod.ru/demo/demo_history.html

← →
DVM © (2009-04-10 12:55) [101]

> sniknik © (10.04.09 00:34) [38]
>

> DVM © (09.04.09 21:29) [12]
> >> вот не было бы ажиотажа с этой мнимой универсальностью
> > Да она не мнимая, она реальная,
>
> против которых я пока выступал в одиночку... :))
>
> ---------------------------
> .... доктор, вы либо туда, либо сюда, а вот это туда сюда
> меня раздражает! © известный анекдот.
>
> ты это, определись, он все таки универсальный или нет, и
> в каком смысле. и если нет, т.е. я прав окончательно и безоговорочно,
> то кто кого учить должен? и причем тут "для чего он нужен"?
> разве от этого сакраментального знания он станет более
> универсальным? что за подмена понятий?

Я убежден, что XML универсальный язык для описания всего чего угодно. Универсальней его только SGML. Он действительно может быть применен где угодно, но расплата за универсальность - гигантская избыточность.

Но я не понимаю, зачем его пытаются применять проталкивать везде где только можно. В некоторых местах его применение абсолютно бессмысленно, а в третьих вредно. Здесь я полностью с тобой согласен.
Также многие просто не понимают назначения XML, но поддавшись моде и массовой истерии, начинают считать XML чем то вроде панацеи и жутко необходимым.

← →
Медвежонок Пятачок © (2009-04-10 12:57) [102]

но расплата за универсальность - гигантская избыточность.

а вознаграждение - чудовищно гигантская гибкость.

← →
Anatoly Podgoretsky © (2009-04-10 13:01) [103]

В кустах сидят, отмалчиваются :-)

ЗЫ: некоторые непонятки в сообщениях, это артефакты от других сообщений, форум висел, а у меня ошибка где-то в сервере. И при массовой отсылки получаются артефакты.

← →
Игорь Шевченко © (2009-04-10 13:07) [104]

Anatoly Podgoretsky © (10.04.09 12:04) [92]

> Игорь так тема то о том, об универсальности и применяемости
> везде. С этого начиналось, это и развенчивается, что не
> надо применять всегда и везде

дай дураку член стеклянный он и руки порежет и член разобьёт :)

Я уже говорил, что XML, как и любое другое средство приносит пользу, будучи употреблено надлежащим образом в надлежащее время. В частности, возможность его валидации стандартными средствами - очень большое преимущество перед другими форматам обмена данными, точно также возможность использования старых программ при расширении состава данных (введения новых тегов) тоже является преимуществом.
А то, что он более объемный по сравнению с plain-текст, например - это недостаток. Тут важно решить, что перевешивает, сумма недостатков или преимуществ.

← →
sniknik © (2009-04-10 13:30) [105]

> Я убежден, что XML универсальный язык для описания всего чего угодно.
т.е. ты за вариант (я там 2 предлагал) понимать универсальность как "в него вы можете впихнуть все что угодно и как вам угодно", а не второго типа "посылайте его куда хотите его везде поймут"...
логично.
проблема только в том, что в массы "подают" вторую интерпретацию, и здесь в этой ветке, если присмотреться она тоже присутствует, даже превалирует.
хотя из первого вовсе не следует второе, даже наоборот, чем большими возможностями универсальности "первого типа" кто то воспользуется для создания обмена, тем труднее его будет прочитать другой стороне, т.е. это сразу минус от универсальности "второго типа"...
для "второго типа" самыми универсальными будут "жесткие" структуры, попросту не допускающие в себе интерпретаций данных по типам/местоположению и т.д. чем ограниченней тем лучше. типа например таблиц... ну, логично же! как этого не понимают, не пойму.

← →
Игорь Шевченко © (2009-04-10 13:54) [106]

Кстати, об обмене данными, совершенно реальные ситуации.

Имеется схема (порядка сотни таблиц) с данными, где-то на полгигабайта.
Схема живет в Oracle 9, кодировка базы данных CL8MSWIN1251
Все данные крайне желательно перетащить в Oracle XE Universal (кодировка базы данных AL32UTF8 (Юникод, если что)). Стандартный import/export в этой ситуации не годится, так как ANSI-данные в Unicode увы, не переносятся, если они русские.

Имеется схема (порядка сотни таблиц) с данными, где-то на полтора гигагбайта. Схема живет в Interbase(Firebird).
Все данные крайне желательно перетащить в Oracle XE тот же, что и в предыдущем примере.

Кто-нибудь подскажет способ, кроме преобразования в XML в исходной базе и импорт XML в принимающей ?

← →
sniknik © (2009-04-10 14:09) [107]

> Кто-нибудь подскажет способ
ADO и его рекордсеты... OLEDB провадеры есть на обоих, из одного делаешь запрос и сохраняешь рекордсет (SaveToFile) в формате pfADTG (pfXML гораздо более ресурсоемкий), у другого загружаешь сохраненный рекордсет "бежиш" по нему, и инсертишь данные через ADOCommand.
Unicode ADO/сами рекордсеты поддерживают, главное в дельфи их не "запороть" (или взять 2009й).

← →
Игорь Шевченко © (2009-04-10 14:28) [108]

sniknik © (10.04.09 14:09) [107]

Программу писать на каждый чих ? Нет, спасибо, способ не годится. Кроме того, ADO ломается на объемах в миллионы записей - уже испытано.

Delphi 2009 я покупать не хочу.

> Anatoly Podgoretsky © (10.04.09 12:04) [89]
> > oxffff (10.04.2009 0:24:36) [36]
>
> Скажем между DBF и XML по этой части практически нет никакой
> разницы,

Ого. Как завернули.

> Anatoly Podgoretsky © (10.04.09 12:04) [90]
> > oxffff (10.04.2009 0:56:42) [42]
>
> > Сложность в том, что значения полей подразумеваются быть
> на данном месте по определенному абсолютному или относительному
> смещению от начала файла.
>
> Для баз данных это не так, только начинающие или недостаточно
> квалифицированые работники опираются на или относительному
> смещению от начала файла. Остальные работают с именами или
> метаданными.

Если вы не поняли контекста, то не следует выдирать предложения из него и переиначивать на свой лад.

Удалено модератором
Примечание: Обсуждение модерирования

Всем кто пытается провивопоставить DBF XML.
XML и DBF нельзя сравнивать.
Поскольку одно из них средство для определения формата и возможностью универсальной проверки его действительности.
А второе это сам формат.

> Программу писать на каждый чих ?
зачем на каждый? один раз. экспорт/импорт в xml тоже же кто то писал прежде чем его можно стало использовать.

> ADO ломается на объемах в миллионы записей - уже испытано.
ну, не знаю, переубеждать не буду но я пробовал миллионы (даже вроде 5ть) и вроде все "жило". тут скорее не от количества записей, а от их объема зависит. рекордсет это все таки данные в памяти. естественно он ей и ограничен.

> Delphi 2009 я покупать не хочу.
не обязательно, главное не пользоваться дельфевскими строками, не отображать и читать после в интерфейсе, сам по себе дельфи как язык то юникод поддерживает, проблема у него с ним в VCL. (на D7 точно нормально можно работать с юникодом/передавать данные. пробовал)

> Вот дела значит последнее предположение из поста мы игнорируем.
> sniknik © (10.04.09 01:07) [45]
там нет оскорбления, там сказано что ты пишешь бред, что есть факт. каждый может прочитать выше и убедиться.

sniknik © (10.04.09 15:05) [113]

а вот из Interbase так и не вышло, пришлось программу писать, да не простую, а с вывертами

> sniknik © (10.04.09 15:09) [114]
> > Вот дела значит последнее предположение из поста мы игнорируем.
>
> > sniknik © (10.04.09 01:07) [45]
> там нет оскорбления, там сказано что ты пишешь бред, что
> есть факт. каждый может прочитать выше и убедиться.

Напоминаю что вы из трех моих предложений, выбросили одно.
И на основании этого делаете выводы.
Это бред. Так устроет?

← →
Городской Шаман (2009-04-10 15:50) [118]

> Медвежонок Пятачок © (10.04.09 09:10) [80]
>
> так как в гомогенной среде вопрос об формате данных не стоит,
> а стоит вопрос об их удобном представлении для обработки
> (бинарный вид).
>
> удобное проедставление в том числе для удобной обработки
> очень хорошо вяжется с xml

Угу, только если в процедуру передавать не бинарный массив, а xml, который нужно сперва распарсить а потом уже обрабатывать, то скорость упадет на пару порядков.

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

← →
Городской Шаман (2009-04-10 16:00) [119]

> sniknik © (10.04.09 09:36) [84]

Я бы сделал так, точнее я так и сделал - пакет данных представляет собой zip-файл в котором в корне лежит data.xml. В нем прописываются примитивные данные типа версии и прочем. Есть данные бинарные(типизированные или нет), где в самом xml прописан путь к ним внутри bin-файла. Так вот binary движком автоматически загоняются в zip файл папку bin и ссылка на них идёт в data.xml. А небольшое количество данных примитивных типов для обработки этих binary лежит в самом xml.

Тоесть вышел из воды с/ухой, когда и скорость и xml.

> вычисление идёт фактически быстрее скорости света

Я бы не стал заходить так далеко и на константы замахиваться.

Поддерживает.. Что за глупое выражение Найти похожие ветки