C#, SQL: Хранение произвольных пользовательских данных в базе данных в виде сериализованных двоичных файлов

Question

Не считаете ли вы плохую практику хранения различных пользовательских данных в базе данных в виде сериализованных двоичных файлов? Это хорошая, плохая или действительно уродливая идея?

Я говорю о довольно произвольных вещах, таких как последнее расстояние сплиттера в форме, последнее значение в текстовом поле поиска, ранее выбранные флажки и т. Д. Вещи, которые следует помнить, что не критично, если они забыты.

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

Это, конечно же, не будет работать с поиском и заказом и тому подобное, но в любом случае это не понадобится, поскольку вы будете обращаться к этим парам значений непосредственно из своего индекса (идентификатор пользователя + источник + ключ). Столбцы также не были бы читаемыми человеком, но опять же это не было бы проблемой. Данные были бы данными, которые могли бы быть устранены без особых проблем.

Любые отзывы об этой идее? Это ужасно? Это хороший? Вы сделали что-то подобное?

Answer 1

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

Answer 2

Я только что вспомнил, что прочитал о API ASP.NET 2.0 Profile.

Процитирую из MSDN

ASP.NET особенность профиля связывает информацию с отдельным пользователем и сохраняет информацию в постоянном формате. Профили позволяют управлять пользовательской информацией, не требуя создания и ведения собственной базы данных. Кроме того, функция профиля ASP.NET позволяет получать информацию о пользователе с использованием строго типизированного API, к которому вы можете получить доступ из любой точки приложения.

Вы можете хранить объекты любого типа, используя профили. Функция профиля предоставляет универсальную функцию хранения, которая позволяет вам определять и поддерживать практически любые данные, сохраняя при этом доступность данных безопасным образом.

С уважением,

Хади TEO

Answer 3

Я использую все это время, потому что наши объекты очень настроены на клиент/установку. Таким образом я могу добавить & удалить свойства без необходимости обновления базы данных.

Мне нужно около 200-300 свойств в строке. Я обнаружил, что такой подход дает мне хорошую гибкость.

Я всегда включаю номер версии в свою двоичную структуру. Поэтому я знаю, какие данные я могу извлечь из него.

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

Answer 4

Было бы лучше, если бы вы пошли на сериализацию XML, а не на двоичную сериализацию. Как и в первом случае, вам не нужно проявлять особую осторожность в отношении обратной совместимости, так как ваш класс эволюционирует с течением времени.

Answer 5

Просто хотел бы добавить в противоположном голосе к обсуждению:

Поставив в сериализованных объектах, вы теряете видимость данных (очевидно), но и сделать его зависит от платформы. Сохраняя вещи в реляционных таблицах, данные теперь могут быть прочитаны любым выбранным вами клиентом. Если в будущем вы решите изменить (или даже добавить другое), то вы потеряете возможность повторного использования тех же данных. Храните клиент и данные отдельно.