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

← →
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 (есть у них там такой класс).
не стоило из-за такой мелочи целый "язык" выдумывать.

sniknik © (29.12.12 12:45) [27]

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

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

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

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

sniknik © (29.12.12 13:02) [31]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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