mariomiguelmigueis Ответов: 5

Создание пользовательских объектов и сохранение их в SQL server

Мне нужно создать приложение для управления пользовательскими объектами со следующими характеристиками:
1) из формы пользователь может создавать базовые пользовательские объекты, которые будут представлять собой детали/компоненты. Например, создайте объект типа "датчик температуры". Этот объект будет иметь пользовательские свойства, такие как "температурный тег (строка)", "Минимальная температура (поплавок)" и "максимальная температура (поплавок)". Другим типом объекта может быть двигатель с такими свойствами, как скорость, мощность и т. д.
Примечание: типы объектов будут создаваться с помощью формы с возможностью их последующего редактирования путем добавления или удаления свойств.
2) в другой форме пользователь сможет создавать экземпляры объектов (sensor1, sensor2, motor1 и т. д.) и просматривать и вводить значения свойств в табличном формате (у нас будут сотни экземпляров).
3) из другой формы пользователь сможет создавать объекты более высокого уровня, которые будут содержать основные свойства (строки, поплавки и т. д.), а также основные объекты, такие как "датчик температуры" или "двигатель".
Например, тип объекта-под названием "кондиционер", который будет иметь 1 Основное свойство называют "установками Град" (строка), объект measuredtemperature (temperature_sensor типа) и объекта вентиляционного (тип двигателя).
4) После определения основных типов (датчик и двигатель) и типов объектов высокого уровня (кондиционер) мы могли бы затем создать несколько экземпляров этого объекта высокого уровня, например AirCon1, AirCon2 и т. д.
Если мы затем изменим тип объекта на любом уровне, то изменения должны каскадировать во всех экземплярах.

Типы объектов и их свойства должны храниться в базе данных, такой как SQL Server.

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

Что я уже пробовал:

Варианты, как я это вижу:
1 - напишите код, который строит таблицы базы данных динамически во время выполнения, когда мы определяем типы объектов, т. е. добавляем столбец для каждого свойства и удаляем/переименовываем по мере редактирования объектов. Вероятно, трудно изменить определения таблиц, когда в них уже есть данные. Кажется грязным.
2 - Создайте статические таблицы с большим количеством запасных столбцов, которые будут распределены по свойствам объекта. Грязно, не знаю, как создавать типы объектов, которые содержат больше типов объектов внутри.
3 - Создайте статическую таблицу со столбцом типа xml и попробуйте поместить все свойства в формат xml. вероятно, сложная для сопоставления XML-столбца на несколько столбцов элемента управления DataGrid?

5 Ответов

Рейтинг:
2

RickZeeland

XML-сериализация-это первое, что приходит на ум, вы уже упоминали об этом.

Другим вариантом было бы использование ОЗР например, Entity Framework, NHibernate, Dapper и т. д.
Смотрите обзор здесь: https://www.slant.co/topics/16667/~платформ-для-С[^]

Но будьте осторожны, ORM, такой как NHibernate, имеет крутую кривую обучения, а документация посредственна, поэтому лучше всего начать с более легкого, такого как Dapper.

Еще одна вещь, которая может вас заинтересовать, - это Механизм Правил вот вам пример: GitHub - NRules/NRules: движок правил для .NET, основанный на алгоритме сопоставления Rete, с внутренним DSL в C#.[^]
И на CodeProject: Проще некуда.Net - простой в использовании движок правил[^]

Maciej Los

Вот это да!

mariomiguelmigueis

Dapper кажется хорошей идеей, чтобы облегчить мою жизнь, однако он, похоже, не может на самом деле создавать/изменять таблицы, если к типу объекта добавляется больше свойств/атрибутов. Сериализация XML также кажется большой работой для того, что я имею в виду.
В сущности, мне нужно что-то вроде таблицы для каждого типа объекта со столбцом для каждого свойства. Количество свойств не будет часто меняться, поэтому можно просто создать новые таблицы и изменить их с помощью команд SQL. Альтернативами могут быть что-то вроде схем EAV, но это отнимет простоту простой прокрутки экземпляров объектов в простом табличном формате. Я также намерен использовать Excel в качестве интерфейса для массовых изменений, поэтому было бы гораздо лучше иметь простой плоский формат.

Рейтинг:
2

James Walsh Jr

Это похоже на вариант использования базы данных документов, такой как Cosmos DB или Mongo DB.

Настройте определения объектов с помощью JSON и включите информацию о версиях вместе с информацией о классификации.

Рейтинг:
1

Maciej Los

В зависимости от способа (метода) сохранения объектов вы можете сбросить их в базу данных sql так же, как и любой другой объект (например, pdf, docx, xlms и т. д.).
Есть специальный тип поля: КАПЛЯ[^]

Для получения более подробной информации, пожалуйста, смотрите: Как читать и записывать данные BLOB-объектов с помощью ADO.NET с помощью Visual C# .NET[^]

Рейтинг:
0

MadMyche

Это можно сделать всего с 3 таблицами в реляционной базе данных, такой как SQL:

Таблица 1 (объект) будет иметь ObjectID, ObjectName и другие базовые элементы, такие как цена.
Таблица 2 (атрибут) будет представлять собой простой список (AttributeID, AttributeName)
Таблица 3 будет соединять таблицы 1 и 2 и иметь дополнительный столбец для значений

Аналогично, существует несколько классов для представления этих таблиц. Разница заключается в том, что класс ObjectClass (тьфу имя) будет иметь коллекцию пар ключ-значение для всех атрибутов, присвоенных объекту и значениям.

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

Этот метод заключается в том, сколько сайтов электронной коммерции выполняют параметрический поиск и фильтры.

Maciej Los

Вот это да!

Richard Deeming

Он же тот самый Модель сущность-атрибут-значение[^]. :)

mariomiguelmigueis

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

MadMyche

1. Для развернутого подхода можно использовать PIVOT в SQL или Excel
2. Таблицы могут быть связаны через INNER JOIN

Jörgen Andersson

Придерживайтесь этой мысли, EAV повлиял на здравомыслие многих разработчиков. Подробнее об этом здесь: https://www.red-gate.com/simple-talk/blogs/when-the-fever-is-over-and-ones-work-is-done/

Тем не менее, это, вероятно, лучший способ пойти еще, и как вы уже поняли, вам нужно (по крайней мере) две таблицы, одна для фактических данных и одна для атрибутов.
Следующий шаг-сделать все как можно проще. Всякий раз, когда руководство приходит к вам, желая получить статистику по одному объекту в сочетании со вторым, в зависимости от значений третьего, сохраняя при этом открытыми варианты для четвертого все еще несуществующего объекта, пришло время искать новую работу. :-)

Обратите внимание, что использование xml или json в базе данных документов-это просто еще один способ сделать то же самое. но чуть менее жесткая и чуть более склонная к разрыву.

О, и никогда не делай вариант 2!

Рейтинг:
0

k5054

Цитата:
Типы объектов и их свойства должны храниться в базе данных, такой как SQL Server.

Является ли SQL определенным требованием? Это кажется хорошим местом, чтобы попробовать NoSql, такие как MongoDB или Redis. Кроме того, возможно, вы можете хранить свою форму в столбце JSON в SQL Server.