Не понял. Вам было лень раскидывать по табличкам и вы вставили в блобы в определённой структуре. Но раскидав по табличкам вы получили бы скорость поиска, например на какую сумму наделали Customer'ы Invoice'ов за такой-то период.

А здесь как? В любом случае придётся по этим блобам лазить и выковыривать эти данны, будь они хоть в хмл хоть в тексте разделённом таблуляцией. Будет это делать сам сервер выполняя XQuery запрос или самописная процедура.

Насколько я знаю все парсеры на пару порядков проигрывают по скорости нормальным скл-серверам. Как с производительностью? Никак? Или вам такие запросы не нужны?

Тогда зачем совать это в БД? Пусть в файловой системе лежит. И не в хмл а сразу в пдф. Открыл, распечатал без всяких преобразований

Флейма нет. С моей стороны по крайней мере.

Одно из правил нормализации - атомарность данных в каждом столбце.

Его практический смысл: при поиске по этим данным не нужно будет вычленять отдельные сегменты информации что увеличит производительность. Например ФИО - можно хранить как Иванов Иван Иванович но если нужно выбрать всех Иванов (например с именинами поздравлять работников/клиентов) то лучше хранить отдельно имя/фамилия/отчество. Но если поиска не предпологается то можно всё валить в кучу, как правило в любом документе есть поле комментариев где лежит что-то неструктурированное.

Так пусть Herr Developer объяснит - производительностью пожертвовали в угоду скорости разработки? Или просто заказами занимается другой отдел и как у них бухгалтеры будут статистику по заказам считать ему не важно?

ну так осветите преимущества/недостатки

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

а то у вас получается

1. Основная инфа (типа дата,сумма,кому-откого) присуствует в "доступном виде".

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


2. Ненадо было лазить по clobам и сейчас ненадо.
В случае с Viper - был бы сделан index и один XQuery запрос с xml - и все
Сейчас все делается до того, как XML данные поподут в базу

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


3. С производительностью все ок

- были тесты? Ок это в 5 раз медленнее или в 50?


4. Это документ и он должен храниться в базе. Как он может выглядить как PDF, как Excel, как CSV, как другой XML, как HTML - это уже view этого документа

- зачем? Если он не обрабатывается а просто хранится? А если он обрабатывается то мож он должен храниться в виде удобном для обработки?


Потребителями этого invoice xml может являються разные системы и люди...

- потребителями данных в обычных табличках так же обычно являются разные системы и люди



=============
тема не раскрыта. Пока вижу только возможность не возиться со структурой малозначимых данных и отложить проблемы с произодительность и валидностью данных на потом.

Проблемы которые возникнут потом:

1.производительность - из моего опыта работы с хмл. Ниже чем в нормальных бд примерно на два порядка.

2.валидность - данные вставляются в блобы в виде хмл. Как проверять что они правильные? При вставке сверять со схемой? Такие возможности есть у сервера или надо писать? А если поменяется схема (например станет обязательным указание даты перечисления денег) что делать со старыми документами? Перепроверять? Кто будет это делать? Так же если схема представления поменяется (например тег Customer будет в новых документах называться TL2)?


2gardenman


авторPerson(
PersonID int ,
Surname smallint , -- длина фамилии
Name smallint , -- дина имени
Patronimic smallint, -- длина отчества
FullName char(60), -- полное имя
Birthday date
)


=8O

а кто будет это Surname smallint высчитывать? Пользователь когда вводит фамилию? По-моему это пример наживания себе геморроя. Вместо того чтоб просто хранить имя и фамилию вводить это в одну строку с указанием длины имени. А когда имя нужно поменять (ошибочно ввели Владлен вместо Владелен) то пересчитать длину.

ну да, проблемы видно. Преимуществ не видно




В этом и "проблема". Я оперирую документом, вы табличками.
-----------------------------
вобщем-то я оперирую данными в разных формах а не табличками или
документами. Можно в хмл, можно в документах, можно в табличках.


2gardenman
--
количество клиенто переаливает за миллион, то для реализации нечеткого
поиска (нажимаешь букавки фамилии - перескакиваешь на нужную) если тащить на
клиента слишком много, особенно при
--

да вроде никакое использование хмл нечёткий поиск не улучшит. Если вы об
этом


Posted via ActualForum NNTP Server 1.3