Умный или Нет: Сохраните сериализированные данные (dotnet-protobuf, protobuf-сеть, json) в Реляционном DB в CF
Я начал читать некоторые сообщения, связанные с буферами протокола. Метод сериализации кажется очень подходящим для передачи данных к и от веб-серверов. Кто-либо рассмотрел использование метода как это, чтобы сохранить и получить данные по самому мобильному устройству? (т.е. замена для традиционной базы данных / orm слой) Мы в настоящее время используем пользовательский основанный на отражении orm. Мы хотим убежать от использования отражения о мобильных устройствах. И, так как мы должны отправить/получить сериализированные данные так или иначе, это походит на хорошую подгонку.
- Где данные были бы сохранены?
- Как данные были бы запрошены?
Имело бы смысл хранить данные в традиционной базе данных (SqlCE или SqlLite) с несколькими "доступными для поиска" столбцами и затем одним столбцом для сериализированных данных?
Мысли? Я в затруднительном положении здесь?
Обновление: эта та же "теория" могла работать на другие типы сериализированных данных также... JSON, например. Я не мог найти опцию NoSQL для того, чтобы сохранить и запросить сериализированные данные по Компактной Платформе. Я интересовался бы той опцией также, если кто-либо знает об одном.
Комментарий к Объектным базам данных я попробовал и db4o и Perst. db4o был абсолютно замечателен работать с. Я использовал его в "реальной жизни" и производительности, удобстве использования, и пригодность для обслуживания была превосходна. Их лицензионные сборы для нашей ситуации были тем, что я буду считать возмутительным. Perst был шагом вниз от db4o, но также и замечательный работать с. Это "просто работало" и было быстро (хотя не рядом как хороший запросить.) Их лицензирование было очень доступно, но что-то в их лицензировании было недопустимо для (большой, известный) корпорация, к которой я заключаю контракт. Это приносит мне туда, где я теперь...
2 ответа
Что ж, раз никто не пытался ответить на этот вопрос, я выскажу свое мнение. Имейте в виду, что я никогда не использовал protobuf (поэтому я еще не ответил), так что все это основано на моем слабом понимании вещей и того, как, если бы мне нужно было решить эту проблему, я бы продолжил.
Во-первых, у меня есть оговорки по поводу встраивания больших двоичных объектов в реляционную базу данных. Это может быть связано с моим плохим опытом, еще во времена каменного века VB6, и может быть неверным, но все же заставляет меня задуматься. Таким образом, я бы, вероятно, исследовал некоторые другие механизмы хранения объектов (например, Perst или db4o ), прежде чем пробовать его.
В качестве должной осмотрительности я бы также, по крайней мере, профилировал вставку больших двоичных объектов в базу данных SQLCE. Почему SQLCE вместо SQlLite или какой-либо другой RDMS? Ну, потому что SQLCE поддерживает TableDirect, который я большой поклонник . Каждый раз, когда вы можете получить доступ к данным без использования медленного обработчика запросов, вы далеко впереди.
Итак, я бы создал таблицу, дал ей пару небольших столбцов поиска, по которым я мог бы искать, а затем столбец изображения, содержащий какой-то большой двоичный объект (фактический двоичный объект не подходит для теста, но он должен быть достаточно близкими по размеру к тому, что вы ожидаете в производстве). Затем я бы добавил индексы для каждого из столбцов поиска.
Я бы заполнил таблицу несколькими тысячами записей, а затем профилировал бы скорость, с которой я мог бы искать желаемый ключ (я знаю, что это быстро), и, что более важно, скорость, с которой я могу регидратировать свои объекты.
Затем я взвешивал затраты (время на разработку, альтернативные издержки, возможности повторного использования и т. Д.) Вариантов и принимал решение. Я бы, наверное, тоже написал в блоге о результатах, так как это похоже на проблему, которая представляет довольно широкий интерес.
Я не видел этого в то время (извините, но я не вижу каждый вопрос, и хотя я слежу за тегом protobuf-net, я не так бдительно слежу за protocol-buffers. Очень интересный вопрос; в плане сравнения с документной базой данных (а не реляционной), я думаю, что такой подход имеет большой потенциал. Это кажется небольшим перегибом, если вы просто сбрасываете блобы, но, по крайней мере, это должно работать. Конечно, я часто использовал подобные установки для загрузки данных в автономные приложения - не конкретно мобильные, но те же концепции применимы.
В частности, такой подход, ориентированный на документы, полезен, когда вы хотите восстановить "систему", т.е. состояние в целом. Они не так просты/гибки для специальных запросов, как реляционные базы данных. Конечно, одним из вариантов является регидратация и запрос в памяти (например, в C# запрос LINQ-to-Objects над регидратированными данными будет почти неотличим от запроса LINQ-to-SQL над данными в реляционной базе данных).