выбор встраиваемой субд

← →
Raziel (2012-12-28 11:05) [0]

Какую встраиваемую СУБД выбрать для создания БД магазина? Пока что выбираю между sqlite и ElevateDB. Количество товаров - около 10к, каждому товару будет назначаться от 2 до 10 картинок.

← →
antonn © (2012-12-28 11:07) [1]

← →
antonn © (2012-12-28 11:08) [2]

рано отправил :)
sqlite :)

← →
sniknik © (2012-12-28 11:09) [3]

> Какую встраиваемую СУБД выбрать для создания БД магазина?
пофиг

← →
Сергей М. © (2012-12-28 11:10) [4]

> Количество товаров - около 10к, каждому товару будет назначаться
> от 2 до 10 картинок

С такими по сути ни о чем не говорящими требованиями - чуть ли не любую..

← →
tesseract © (2012-12-28 11:47) [5]

Да хоть DBF. Разницы никакой.

← →
MsGuns © (2012-12-28 12:05) [6]

Метлу.
А если серьезно - 1С

← →
tesseract © (2012-12-28 16:21) [7]

> А если серьезно - 1С

Для чисто количественно-картиночного учета. В 7.7 картинки тяжко вставить.

← →
Ega23 © (2012-12-28 16:30) [8]

> Количество товаров - около 10к, каждому товару будет назначаться
> от 2 до 10 картинок.

Достаточно TCliendDataSet. :)

← →
знайка (2012-12-28 16:46) [9]

А почему именно встраиваемую? этож магазин..

← →
Jeer © (2012-12-28 17:11) [10]

на мобиле:)

← →
Kerk © (2012-12-28 17:17) [11]

> Ega23 © (28.12.12 16:30) [8]
>
> > Количество товаров - около 10к, каждому товару будет назначаться
> > от 2 до 10 картинок.
>
>
> Достаточно TCliendDataSet. :)

XML !!! :)

← →
Ega23 © (2012-12-28 18:47) [12]

> XML !!! :)

На 10 тысяч с бинарными данными - не факт.

← →
Anatoly Podgoretsky © (2012-12-28 19:57) [13]

На 60 000 (10к + 10К * (2-10))
При этом это среднее величина, а может быть и 110К

← →
tesseract © (2012-12-28 22:04) [14]

> Kerk © (28.12.12 17:17) [11]
>
> > Ega23 © (28.12.12 16:30) [8]
> >
> > > Количество товаров - около 10к, каждому товару будет
> назначаться
> > > от 2 до 10 картинок.
> >
> >
> > Достаточно TCliendDataSet. :)
>
> XML !!! :)

Регулярно открываю xml на 10-100 мегабайт. Врагу не пожелаешь, он не предназначен для работы с данными - только для обмена.

← →
Jeer © (2012-12-28 22:39) [15]

> Врагу не пожелаешь,

Ну почему - как раз пожелаем-с:)

← →
Kerk © (2012-12-29 00:14) [16]

Бинарные данные надо кодировать и в CDATA класть!

Да шучу я, шучу :)

← →
sniknik © (2012-12-29 10:38) [17]

> не предназначен для работы с данными - только для обмена.
ИМХО конечно, но он и для обмена не особо предназначен... во всяком случае с обычным dbf, сколько работал столько проблем как с ним не было.
ну и да, если объективно, все проблемы не собственно xml-я, а того, что его считают "универсальным" (есть такой миф, кто то внушил "среднему звену") просто по факту его наличия (невзирая на левые парсеры, отсутствие логики в данных, и т.д., а после "у нас же xml, почему не можете использовать?").

← →
Медвежонок Пятачок © (2012-12-29 11:35) [18]

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

← →
Медвежонок Пятачок © (2012-12-29 11:43) [19]

.... бабушки из бухгалтерии могут прислать dbf в котором есть мемо поля, но без файла с этими самыми мемо полями

← →
знайка (2012-12-29 12:01) [20]

> "у нас же xml, почему не можете использовать?"
Так и действительно, а почему собственно?

← →
Медвежонок Пятачок © (2012-12-29 12:05) [21]

да просто капризничают по ходу.
либо не умеют правильно с ним работать.

← →
Игорь Шевченко © (2012-12-29 12:09) [22]

sniknik © (29.12.12 10:38) [17]

Руки выпрямлять не пробовал ?

← →
sniknik © (2012-12-29 12:25) [23]

Медвежонок Пятачок © (29.12.12 11:35) [18]
не поспоришь, можно и dbf "кривой"/не подходящий сделать, но вот не было проблем... и с 1С-ным тоже. и речь не о том можно сделать глючнее/наоборот правильнее, а о том как оно есть/причина.

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

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

← →
Медвежонок Пятачок © (2012-12-29 12:33) [24]

но вот не было проблем... и с 1С-ным тоже.

Да у меня то тоже как то не было проблем с желтым дбф.
Открываем..... чего говорите? Кракозябры показались?
Не вопрос, открываем как двоичный, меняем тридцатый байт, закрываем. Кракозябры превратились в русский текст.
Открываем .... что говорите? не хватает каких-то там dbt?
не проблема. Открываем как двоичный, правим заголовок, мемо поля больше не нужны.

Все просто. Но зато никакого мифа универсальности нет.

← →
Медвежонок Пятачок © (2012-12-29 12:35) [25]

Да, еще совсем забыл.

Мне в жизни повезло больше.
Я об xml и его универсальности узнал сам в процессе использования.
Не от эффективных манаджеров среднего звена.

← →
Игорь Шевченко © (2012-12-29 12:43) [26]

sniknik © (29.12.12 12:25) [23]

Тяжело видеть бездоказательные утверждения со ссылками на злобно гнетущих менеджеров.

← →
sniknik © (2012-12-29 12:45) [27]

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

← →
sniknik © (2012-12-29 12:49) [28]

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

← →
Игорь Шевченко © (2012-12-29 12:53) [29]

sniknik © (29.12.12 12:45) [27]

А что, если аналогичный файл пришлют в виде dbf, с псевдоформатированием, его преобразовать и понять легче ? :)

← →
sniknik © (2012-12-29 13:00) [30]

вы вообще читаете или нет?

легче не легче, какая разница? такого НЕ БЫЛО, а сейчас ЕСТЬ, сплошь и рядом. раньше договариваясь об обмене присутствовал специалист, с обоих сторон, сейчас мало того спецов нет, так и те что есть "классом ниже" в понимании (правильно, это же не нужно, на все есть один ответ, варианты даже не рассматриваются... ;().

← →
sniknik © (2012-12-29 13:02) [31]

+
> А что, если аналогичный файл пришлют в виде dbf
> dbf подобных вольностей не допускал в принципе.

← →
Игорь Шевченко © (2012-12-29 13:08) [32]

sniknik © (29.12.12 13:02) [31]

> dbf подобных вольностей не допускал в принципе.

Это почему ? В dbf нельзя организовать схему с псевдоформатированными данными ? Какое-то ограничение формата на строковые поля ?

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

XML как формат тут в чем виноват ?

← →
знайка (2012-12-29 13:13) [33]

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

← →
sniknik © (2012-12-29 13:39) [34]

> XML как формат тут в чем виноват ?
а если почитать "без фанатичного блеска в глазах", то кто его "как формат" обвинял?

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

← →
Медвежонок Пятачок © (2012-12-29 13:54) [35]

А что, если аналогичный файл пришлют в виде dbf
> dbf подобных вольностей не допускал в принципе.

Да вот хренушки.
Присылали dbf сделанный из книги йокселя.
Одна сущность может может быть в одной, двух и трех строках.
А может и в большем количестве.
И никаких признаков того, что эта одна и та же сущность просто нет.
Хотя нет, вру.
Огорожено было рамочками. В одной рамочке все с строки - это одна сущность.

Потому что йоксель был заточен на рассматривание глазами.

← →
sniknik © (2012-12-29 13:58) [36]

кстати, вот, было бы смешно, если бы не было так грустно...
сегодня, прямо вот сейчас, подарок под новый год, не проходит регистрация точки в МТС/МГТС... ошибка ("не совпадает тип поля") обмен в xml.
причина несколько в ином, тип и там там строка, просто никто не удосужился согласовать размеры полей, в итоге у "них" 50 символов, у "нас"(агента) 62, а xml-ю пофигу естественно, а dbf это было бы одним из главных параметров.
и естественно можно было бы "курить" маны самого МТС-а и т.д. (обзывать всех "земляными червяками", без рук) но вот что делать посредникам которые напрямую не завязаны, а работают через менеджеров (часто их спецом "дистанцируют" от прямых контактов, чтобы не перешли не дай бог)? как ни банально...
в итоге все уже квасят, а тут "разруливаю" чьи то последствия.

← →
знайка (2012-12-29 13:59) [37]

> я работаю не замкнуто в рамках одной конторы, а на связи
> со многими, и везде вижу примерно одинаковое положение.
Ну мы тоже не сами по себе. Например покупаем для себя и клиентов у 3-их контор некоторые xml-feed"ы, сервисы под которые крутятся вот уже несколько лет 24/7 и никаких проблем нет.
Было 1 или 2 переделки, но предварительно получили письма, в которых было расписано что и почему изменилось, и когда вступит в силу.
А вот изменения вносятся на раз-два .. потому что все просто и понятно.
Так что у нас опыт несколько другой, и как кажется правильный. ;)
Вы же сами вроде как с джсоном имеете(имели) дело, а он похуже xml, в плане вседозволенности, к нему претензий нет? :)

← →
sniknik © (2012-12-29 14:01) [38]

> Да вот хренушки.
> Присылали dbf сделанный из книги йокселя.
это опять про "бабушек" с ручным формированием? я несколько про иное...

← →
sniknik © (2012-12-29 14:07) [39]

> сервисы под которые крутятся вот уже несколько лет 24/7 и никаких проблем нет.
ключевое тут, "несколько лет" похоже, через несколько любой обмен будет "зачищен" от "непоняток".

> Вы же сами вроде как с джсоном имеете(имели) дело, а он похуже xml
и с ним тоже, со многими имею дело (велосипедов на основе текста "вагон и маленькая тележка"). и тут парадокс, пусть он похуже (хотя чем?) но проблем с ним нет вообще. хотя он не так распространен, т.что... а вот dbf - xml сравнивать есть что.

← →
sniknik © (2012-12-29 14:14) [40]

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

← →
знайка (2012-12-29 14:28) [41]

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

> хотя чем?
Ну хотябы тем, что для него нет возможности расписать xsd (схему) и соотв. валидировать? хотя кто его знает, может уже понаделали и для него... я не встречал. :)

← →
Медвежонок Пятачок © (2012-12-29 14:31) [42]

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

Никакого sql-подобного поиска там нет.
А если сделать в js какому-то действительно сложному объекту енкоде - то еще бабушка надвое сказала что из этого выйдет.

← →
sniknik © (2012-12-29 14:37) [43]

> А сделали за пару дней. День читали, и день имплементировали.
т.е. пришли на готовый сервис у которого данные в xml? где тут разработка? или вы для сервиса с данными в MySql например, сделали обмен "наружу" в хмл, а кто-то другой делал клиента (или наоборот)?

p.s. сакцесс стори и у меня хватает. могу их рассказать. надо? а смысл? доказать, что если есть проблемы, значит у них руки кривые? или что? что одна "сакцесс" изменит в статистике (кривой и убогой, собранной одним человеком, но тем не менее не на одном случае. тем более именно для этого человека)?

← →
Медвежонок Пятачок © (2012-12-29 14:50) [44]

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

← →
Игорь Шевченко © (2012-12-29 14:54) [45]

sniknik © (29.12.12 13:39) [34]

> а если почитать "без фанатичного блеска в глазах", то кто
> его "как формат" обвинял?

пост [17]

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

И о чем это говорит ? О том, что в конторах, с которыми ты работаешь на связи также не хватает специалистов ?
Опять же, это не XML виноват.

Мир использует (успешно) XML в качестве одного из стандартов обмена данными, чем дальше, тем больше. А местечковые dbf отмирают.

← →
sniknik © (2012-12-29 14:55) [46]

> похоже здесь обсуждаются кривые контрагенты, а не кривые форматы.
sniknik © (29.12.12 13:39) [34]
> а если почитать "без фанатичного блеска в глазах"

sniknik © (29.12.12 10:38) [17]
> не предназначен для работы с данными - только для обмена.
ИМХО конечно, но он и для обмена не особо предназначен... во всяком случае с обычным dbf, сколько работал столько проблем как с ним не было.
ну и да, если объективно, все проблемы не собственно xml-я, а того, что его считают "универсальным" (есть такой миф, кто то внушил "среднему звену") просто по факту его наличия (невзирая на левые парсеры, отсутствие логики в данных, и т.д., а после "у нас же xml, почему не можете использовать?").

← →
sniknik © (2012-12-29 15:08) [47]

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

к примеру как то давно прислали данные базы mssql в хмл (вернее программы, без системных таблиц)... 2 гига архив, для того чтобы найти глюк в структуре (!). сбой был, диск посыпался, и местный админ не знал что делать. (а вот сделать "необъятный" xml, выгружая и склеивая 2 недели куски из программы хватило).
тут был единственный вариант - исходная база, либо прямо файл, либо бэкап. но менеджер (не согласовывая) требовал xml все две недели (подозреваю что и не знал ничего другого).

← →
Игорь Шевченко © (2012-12-29 15:10) [48]

sniknik © (29.12.12 14:55) [46]

Я процитирую:

"XML — язык разметки, позволяющий стандартизировать вид файлов-данных, используемых компьютерными программами, в виде текста, понятного человеку;
XML поддерживает Юникод;
в формате XML могут быть описаны такие структуры данных, как записи, списки, деревья, форматированный текст;
XML — это самодокументируемый формат, который описывает структуру и имена полей так же как и значения полей;
XML имеет строго определённый синтаксис и требования к анализу, что позволяет ему оставаться простым, эффективным и непротиворечивым. Одновременно с этим, разные разработчики не ограничены в выборе экспрессивных методов (например, можно моделировать данные, помещая значения в параметры тегов или в тело тегов, можно использовать различные языки и нотации для именования тегов и т. д.);
XML — формат, основанный на международных стандартах;
Иерархическая структура XML подходит для описания практически любых типов документов, кроме аудио и видео мультимедийных потоков, растровых изображений, сетевых структур данных и двоичных данных;
XML представляет собой простой текст, свободный от лицензирования и каких-либо ограничений;
XML не зависит от платформы;
XML является подмножеством SGML (который используется с 1986 года). Уже накоплен большой опыт работы с языком и созданы специализированные приложения;
XML не накладывает требований на порядок расположения атрибутов в элементе и вложенных элементов разных типов, что существенно облегчает выполнение требований обратной совместимости;
В отличие от бинарных форматов, XML содержит метаданные об именах, типах и классах описываемых объектов, по которым приложение может обработать документ неизвестной структуры (например, для динамического построения интерфейсов);
XML имеет реализации парсеров для всех современных языков программирования;
Существует стандартный механизм преобразования XSLT, реализации которого встроены в браузеры, операционные системы, веб-серверы"

"Миф об универсальности" таки имеет под собой основания ;)

← →
Игорь Шевченко © (2012-12-29 15:12) [49]

sniknik © (29.12.12 15:08) [47]

Какой смысл обсуждать чьи-то кривые руки ? Не понимаю.

← →
Медвежонок Пятачок © (2012-12-29 15:13) [50]

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

ps я тоже встречаю такое:

<root>
<item>name=value;another_name=another_value</item>
</root>

дураки - они живучее тараканов

← →
sniknik © (2012-12-29 15:13) [51]

> "Миф об универсальности" таки имеет под собой основания ;)
таки, универсальности в смысле "на нем можно сделать все", а не как понимается "раз xml значит универсально, что и как ни делай".

← →
sniknik © (2012-12-29 15:15) [52]

> ps я тоже встречаю такое:
тебе везет если это всего раз. у меня что-то похожее, аналогичное где-то раз в неделю.
и повторяюсь с dbf такого не было... просто не смогли бы.

← →
Игорь Шевченко © (2012-12-29 15:16) [53]

sniknik © (29.12.12 15:13) [51]

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

← →
Медвежонок Пятачок © (2012-12-29 15:20) [54]

на нем можно сделать все

А что не можно на нем?

← →
sniknik © (2012-12-29 15:23) [55]

кстати вопрос, раз уж такая пьянка...
очень часто имена тегов в разном регистре т.е. один xml и <field><Field> или в одном одинаково, а во втором одноименном по сути, в другом регистре.
как боретесь? если встречали.
можно мелкософтский обьект (XMLDocument) сделать регистронезависимым для имен тегов (для данных/все скопом "up-нуть", нельзя... иногда это "ключи")?

← →
Inovet © (2012-12-29 15:24) [56]

> [29] Игорь Шевченко © (29.12.12 12:53)
> А что, если аналогичный файл пришлют в виде dbf, с псевдоформатированием,
> его преобразовать и понять легче ? :)

В некоторых банках, не будем показывать пальцем, ибо и так на слуху, официальный формат приёма данных от клиентов был примерно такой.
Файл DBF
поля f1, f2, f3, f4, и т.д., все символьные сколько-то там рамером
Образец заполнения как-то по полям это размазано и пустые записи обязательно
Органицация Рога и копыта Р/с 12345678901234567890 Количество 2 ФИО Паспорт Номер счёта сумма Иванов Иван Иванович 12 34 567890 0123456789000000001 1000.00 Петров Пётр Петрович 12 34 567891 0123456789000000002 2000.00 Итого 3000.00

← →
sniknik © (2012-12-29 15:29) [57]

> Доводы на уровне - Pascal плохой язык, потому что на нем программисты в одной конторе и еще в нескольких написали программы с ошибками. Вот если бы они на С писали, проблем бы не было.
как раз наоборот, C "плохой" т.к. часто встречал ошибки C-ников, на паскале попросту не возможных (на игнорирование типа например, когда вместо гуида инт передавали, в случае значения 0, вместе с размером структуры в которой содержалась)

← →
sniknik © (2012-12-29 15:32) [58]

> В некоторых банках
тоже сталкивался... была 2-ная фамилия и соответственно глюк. я разбирался (менять формат не стали).

← →
Медвежонок Пятачок © (2012-12-29 15:32) [59]

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

sniknik © (29.12.12 15:29) [57]

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

Можно языки переставить местами, смысл не меняется.

Inovet © (29.12.12 15:24) [56]

Ты к чему это написал ?

> sniknik (29.12.2012 15:08:47) [47]

Дуракам закон не писан.

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

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

> [50] Медвежонок Пятачок © (29.12.12 15:13)
> <root>
> <item>name=value;another_name=another_value</item>
> </root>

В налоговой так сделали, раньше нормальный был, когда сразу после текстового XML ввели.

> [58] sniknik © (29.12.12 15:32)
> была 2-ная фамилия и соответственно глюк.

Двойная фамилия - фигня в сравнение с остальным в этом "формате".

sniknik © (29.12.12 15:39) [63]

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

В dbf объявить все поля символьными с длиной 255. И пихать в них всякую чушь

> [60] Игорь Шевченко © (29.12.12 15:36)
> Inovet © (29.12.12 15:24) [56]
>
> Ты к чему это написал ?

А не понятно? К тому, что в dbf ещё и не такие чудеса вытворяли.

> [64] Inovet © (29.12.12 15:46)
> > [50] Медвежонок Пятачок © (29.12.12 15:13)
> > <root>
> > <item>name=value;another_name=another_value</item>
> > </root>
>
> В налоговой так сделали, раньше нормальный был, когда сразу после текстового XML ввели.

Пардон, думал ты про атрибуты. В налоговой атрибуты сделали. Ну а в твоём примере совсем уж что-то непонятное.

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

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

> Однозначно dbf негодный формат
ну вот зачем это? миф создаете? где было, что формат виноват?
уже второй раз - речь не про формат. читайте без "фанатичного блеска в глазах"

> [71] sniknik © (29.12.12 16:10)
> уже второй раз - речь не про формат

Я-то понял твою мысль - раз XML уневерсальный, значит там, "где-то там" по мнению менеджеров, есть некая пара кнопок "Выгрузить"/"Загрузить", которые сами всё, что менеджерам захочется, выгрузят/загрузят.

Правильно?

> [59] Медвежонок Пятачок © (29.12.12 15:32)
> Вот это "Итого" меня всю жизнь прикалывало.

Это объяснимо, не привязываясь к формату. Есть в бумажном документе такое поле, значит и в электронном оно должно быть, для полного соответсвия. XML здесь как раз и подходит. Что до DBF, так тогда уж пришлось бы не одну таблицу передавать, а несколько десятков или денормализовать до маразма.

← →
Smile (2012-12-29 16:39) [75]

Похоже, что ветка себя исчерпала (даже независимо от того, что в ней принимают участие и модераторы сайта)
:(

sniknik © (29.12.12 16:06) [70]

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

Надо было в dbf вложить :)

Еще раз - ты в [17] написал, что XML не пригоден для обмена, потому что у ваших контрагентов кривые руки, а у вас не хватает специалистов.
Точно по таким же критериям непригодным для обмена является любой формат, даже не существующий.

> непригодным для обмена

даже этот форум, хотя - не самое худшее, что видел.
Потому и бываю здесь.

> Я-то понял твою мысль - раз XML уневерсальный, значит там, "где-то там"...
> Правильно?
типа того, по сути. а вообще у нас нет кнопок (платежи/кассы/события/... взаимодействие автоматом).

> Еще раз - ты в [17] написал, что XML не пригоден для обмена, потому что ...
он через чур разрекламирован, через чур "на слуху", через чур "универсальный" из-за чего у многих мнение, что ничего больше не нужно знать/определять (данные/размерность/структуру/...)
вот был бы он типа json-а, на который договаривающиеся товарищи "стойку" делают - "ась? в чем вы сказали у вас обмен?... ээээ, а давайте я вас со специалистом соединю". и все бы было ок.

← →
Sergey Masloff (2012-12-31 19:56) [80]

> XML как формат тут в чем виноват ?

+100500

Я курирую B2B направление в крупной организации. Годы когда основной объем был в PDF вспоминаю как страшный сон.

XML решил много проблем.
Например автоматическая валидация документов (стандартными средствами).
Проще документировать и поддерживать документацию в актуальном состоянии. Ни и вообще много чего.

← →
Sergey Masloff (2012-12-31 19:57) [81]

И кстати с новым годом наступающим всех. Я только отработал на сегодня и второго в 8 утра на работу ;-)

>> XML как формат тут в чем виноват ?
> +100500
> а если почитать "без фанатичного блеска в глазах", то кто его "как формат" обвинял?

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

> Я только отработал на сегодня и второго в 8 утра на работу ;-)
наверняка XML "подсуропил" %) был бы dbf (или нормально запротоколированный xml, так уж и быть) то вышел бы как все нормальные 9го числа...

ну, и с наступившим всех. поддержу традицию.

← →
Sergey Masloff (2013-01-02 13:31) [83]

> наверняка XML "подсуропил"

Нет ;-)

> sniknik © (01.01.13 12:31) [82]

Наличие возможности - сути не меняет.
Сейчас есть возможность, так картинку помещают.

выбор встраиваемой субд Найти похожие ветки