price in database (насколько это целесобразно)

[IMB]

Приветствую!
Я работаю в небольшой торговой фирме. Прайс руководство держит в xls-формате. Недавно начался переход на OpenOffice. Вопросов с открытием прайса нет, вопрос есть в скорости работы Calc-а с файлом прайса. Файл имеет размер, в среднем, 6 МБ. Открывается долго, да и при сохранении периодически возникают "зависания" Calc-а. Это одна из причин почему на некоторых местах все еще стоит MicrosoftOffice.
Собственно я хочу попросить совета по некоторым вопросам:
- насколько целесообразен перевод прайс в базу данных или из-за этого объема не стоит искать "приключений себе на голову"
- если перевод имеет смысл то что лучше выбрать - sql-базу, например mysql, или OpenOfficeBase, насколько я понимаю это аналог MicrosoftOfficeAccess
- возможно ли из mysql напрямую экспортировать данные в такие форматы как xls, pdf, я знаю что есть возможность экспорта в текстовые файлы с разделением данных запятой/точкой, конечно возможно потом данный файл вставлять в Calc и сохранять в нужном формате, но хочется в один шаг.
Буду рад услышать Ваши соображения по данному вопросу. Спасибо.

[serzh-z]

IMB, если есть человек, который спроектирует БД и напишет интерфейс к прайс-листу, то смысл перенести всё в БД определённо есть, не обязательно в MySQL, можно обойтись даже SQLite например, в частности если число записей в прайсе не превышает нескольких тысяч.

[IMB]

IMB, если есть человек, который спроектирует БД и напишет интерфейс к прайс-листу, то смысл перенести всё в БД определённо есть, не обязательно в MySQL, можно обойтись даже SQLite например, в частности если число записей в прайсе не превышает нескольких тысяч.

Ну этим человеком скорее всего буду я. Меня смущает, собственно говоря, именно объем - имеется некий стереотип что база данных это нечто большое. Ну а про написание - будем осваивать php и иже с ним. Думается проще организовать web-доступ, чем писать клиентскую часть.
P.S. Модераторы, что то мне кажется что тему открыл я несколько не там. Если не затруднит, перенесите в соответствующий раздел. Пожалуй более точное месторасположение - Тематический флейм. Спасибо.

[serzh-z]

Думается проще организовать web-доступ

Да.

БД - это не обязательно нечно большое - если даже записей больше тысячи, не устраивает скорость и общий доступ к файлу таблицы, то вполне логичным выглядит использование простой SQL-базы.

[IMB]

Спасибо. С целесообразностью более-менее ясно. А что насчет экспорта данных в файлы? Приоритетными являются xls и pdf.

[sarutobi]

IMB,
если будете осваивать php то модули экспорта в xls и pdf там присутствуют (для xls - модуль на php, для pdf - встраиваемый so/dll вроде бы). Если другой язык - то соотвественно надо смотреть там.
Хинт: любая СУБД ничего не знает о представительском формате(xml, xls, pdf etc....), который нужен на выходе. она всего лишь обеспечивает эффективную обработку данных пользователя.

[diesel]

Спасибо. С целесообразностью более-менее ясно. А что насчет экспорта данных в файлы? Приоритетными являются xls и pdf.

для perl'а, например, есть модули которые позволяют xls делать, возможно для php или что вы там использовать будете тоже что-то подобное окажется.

ЗЫ: ыыы, долго писал.

[serzh-z]

любая СУБД ничего не знает о представительском формате(xml, xls, pdf etc....), который нужен на выходе

Ну, скажем, не так уж любая - некоторые поддерживают тип данных навроде EXTFILE (чем-то похоже на блоб), и с помощью специальных фильтров умеют даже индексировать это поле...

[IMB]

Спасибо. Есть над чем подумать.

[MadDog]

Прайс руководство держит в xls-формате.

Было и у нас нечто подобное. В некоторых случаях проблема решилась простым сохранением в родной формат Calc, т.е. *.ods. Если же необходимо отсылать клиентам, то этот файл из Calc тупо экспортируется в pdf. Клиентам же только прочитать/распечатать надо.

[sarutobi]

[offtop]
serzh-z,
смысл extfile применимо к данному случаю или вообще?
ответ можно в личку
[offtop]

[igorv]

любая СУБД ничего не знает о представительском формате(xml, xls, pdf etc....), который нужен на выходе

Ну, скажем, не так уж любая - некоторые поддерживают тип данных навроде EXTFILE (чем-то похоже на блоб)...

В том-то и дело, что поле такого типа - всего лишь контейнер для произвольного содержимого. Это значит что "любая СУБД ничего не знает о представительском формате".

[IMB]

Прайс руководство держит в xls-формате.

Было и у нас нечто подобное. В некоторых случаях проблема решилась простым сохранением в родной формат Calc, т.е. *.ods. Если же необходимо отсылать клиентам, то этот файл из Calc тупо экспортируется в pdf. Клиентам же только прочитать/распечатать надо.

Прайс не отсылается клиентам, его выкладывают на сайте. Я провел опыт с прайсом - 6 МБ xls ужался до 0.5 МБ ods. По размеру - замечательно, но скорость открытия, даже по сравнению с xls, возросла заметно. С конвертацией в pdf тоже не все однозначно. В прайсе для "внутреннего" использования присутствуют дополнительные колонки с ценами, которые не надо разглашать, да и за время использования файл уже подбили под формат средствами Excel, а при открытии в OpenOffice "плывут" страницы. Ну и будем учитывать "консерватизм" людей.
Но насчет хранения прайса в базе данных я подумаю очень серьезно, глядишь получится интегрировать в сайт.

[v04bvs]

Сделайте web-доступ и всё. У пользователей будет возможность удобно работать с прайсом, при желании легко навешиваются нужные функции, всё отлично интегрируется с сайтом, естественным образом делается разграничение прав. HTML прекрасно распечатывается, в нём превосходные средства отображения таблиц, он куда кроссплатформеннее, чем ексель. Прайсы в екселе - самое дебильное, что можно придумать, уж извините.

Единственное - консерватизм, ну тут уж ваша задача как разработчика - сделать миграцию как можно более простой.

[serzh-z]

sarutobi, вообще, в принципе igorv уже всё сказал.