Как можно из БД сделать XML?
 

Есть простая БД: 100 полей и 100 записей, а на пересечении их некие строковые значения. Всего получается 10 тыс. значений.
Можно ли эту БД перегнать в XML, чтобы также можно было задать два параметра (номер поля и номер строки) и получить искомую запись?

Э, с помощью любого серверного языка и SQL запроса.

Я не про конвертацию. Какая должна быть структура искомого XML чтобы мне было быстро и удобно осуществлять поиск потом нужной записи по двум параметрам?

не?

Если мы говорим про работу из AS3, то примерно так:

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

Ну если это лучшее решение, тогда не стоит переходить на XML. Весь вопрос был в размере и скорости доступа, но если так как я и представлял, тогда игра не стоит свеч. Размер XML-файла 3-4 МБ, поиск 2-3 секунды:(

Одним из ключевых достоинств использования БД всегда считалась скорость доступа. Не пытайтесь обскакать БД в этом вопросе - долгие хлопоты, лишние слезы. :)

Если БД живет на сервере, а XML уже загружен на клиента и прошел предварительную обработку (то же индексирование), то за счет потерь на коммуникацию с сервером вариант с XML может дать существенно большую скорость.

К сожалению, а данном случае недостаточно информации, чтобы советовать что-то конкретное.

Да, конечно. Но это должен быть очень специфичный случай... Даже не могу сходу придумать такую ситуацию.

Легко. Информационный киоск.

И? OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact, в общем локальные решения? Нет?

Зачем?

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

Ну, может быть есть отдельные случаи когда это не так, но не сталкивался...

Есть достаточно широкая область пограничных объемов. К примеру, диапазон 10,00-1,000,000 записей достаточно мал, чтобы хранить данные в памяти и не усложнять систему лишними внешними зависимостями и достаточно велик, чтобы последовательный поиск был слишком долгим для практического использования.

Соответственно, если задача решается целиком средствами одного инструмента, но взамен предлагается наставить еще кучу всего, то возникает вопрос, который я озвучил выше:

Если в тех условиях, когда справляется один Flash, мы добавим еще и OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Sav Zigzag, Microsoft SQL Server Compact (желающие пусть впишут свое) -- в чем будет дополнительное счастье? Помним, что все это потребует затрат на интеграцию и организацию обновления локальной базы.

эта цифра 10,00 == 1000 или ==10?

Миллион записей это, всё же, уже не мало. Совсем не мало. Конечно, организация интеграции требует от прогера телодвижений, но если действительно есть заинтересованность в оптимальном результате, то сделать их все же придется. Что касается обновлений, переноса, оптимизации, то это опять же стихия БД. Они под это заточены изначально и в этом, отчасти, их смысл и состоит. То есть это тоже одни из основных задач которые решаются средствами БД.

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

Но, не буду спорить (хотя вроде, как уже и спорю) :)Может вы и правы, я не сталкивался с такими ситуациями.