Адаптивная база данных в .NET 4.x

Пипол, привет!

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

Body: задача сделать "адаптивную базу данных" на mssql. Понятно что при таком раскладе EF отпадает (ну так же?) и остаётся только чистый ADO.NET. В принципе написать класс "репозиторий" ну и юзать его методы не столь глобальная проблема как шок от словосочетания "адаптивная база данных". Кто то может делал такое? Есть опыт хождения по камням? Есть примеры?

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

Эпилог: если есть у кого-то наработки, примеры или советы касаемые данного вопроса - на пожалейте, поделитесь, помогите.

Добавлено через 35 минут
Самый наверно режущий глаз вопрос - а как узнать тип данных без явного индикатора?
у нас данные в один и тот же момент времени могут иметь 2 состояния:
-тип колонки в бд (в том случае если таблица с этим столбцом уже есть в бд (для примера int))
-тип в пришедшем файле (ну предположим что мы божественным образом всё отпарсили и знаем точный тип - double)
Ок, и что дальше? Одна таблица, одна колонка и 2 разных типа данных!
конвертить к первому или ко второму? и на каких основаниях? Да и вообще как у строки можно определить "точный тип данных"??? В системе же нет стандартного парсера который на основе своей внутренний логики скажет это: short, ushort, int, uint, long, ulong или может double, decimal, float. Как тип данных определить?

0

DarkOrk, интересная задачка.

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

Таблицу метаданных заполнять по данным, полученным из бажественного парсера.
Если через n дней после начала работы в колонке, которую мы посчитали интовой, появится запятая, можно будет просто поменять метаданные, указав в них, что колонка то у нас, оказывается, вещественного типа была. И не надо будет перезаливать ничего, всё учтётся на следующей итерации получения данных из адаптивной базы.

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

В принципе ничего сложного. А ентити тут не нужны, для этого грубоваты, поскольку эта задача не про отвёрточную сборку. Хотя, конечно, можно ради ентитей извратиться через МСБилд, но это будет лишнее.

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

Это вступительное задание на работу что ли такое ?

1

Спасибо. А то уже думал некто мне нечего не подскажет.

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

Когда юзер делает запрос мы генерируем временную табл. на основе типов из метатаблицы и просим бд сразу же начать парсить всё то что когда-то залил юзер и соответственно, добавить это в временную таблу. По завершению чего отправить её клиенту.

По части определения типа данных, вы так отписались что или "единственный способ - это явно проверить на все основные типы" или есть какой-то простой вариант о котором я не знаю, а вы не говорите?!



По поводу хранения в "первичном" виде. В принципе да.. но... там была ещё подзадача, о которой я не сказал ввиду её неактуальности (если бы мы распарсили данные сразу). Нужно дать возможность изменять данные из клиента в бд.
Если бы была таблица в завершённом её виде (в бд) то просто отобразив её в контроле для данных (DataGrid к примеру) мы б имели бы возможность обновить отредактированную строку через UPDATE, но храня нерасспарсеный вариант данных то придётся делать хранимую процедуру которая будет выполнять функции команды UPDATE (постоянно парсить все данные и по переданным параметрам искать и заменять значения), так?

0

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

Так.

Сообщение от DarkOrk Когда юзер делает запрос мы генерируем временную табл. на основе типов из метатаблицы и просим бд сразу же начать парсить всё то что когда-то залил юзер и соответственно, добавить это в временную таблу. По завершению чего отправить её клиенту.

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

Сообщение от DarkOrk По части определения типа данных, вы так отписались что или "единственный способ - это явно проверить на все основные типы" или есть какой-то простой вариант о котором я не знаю, а вы не говорите?!

Простых вариантов много, но если мы пишем что-то серьёзное, то надо разбирать ручками. Например, что такое 20151212? Дата или просто номер? А что такое 03.05.10? Если это дата, то как соотнести цифры с её частями? А что такое 16/10? Дата или криво введённый коэффициент трансформации трансформатора тока? Должен быть какой-то набор шаблонов, которые будут применяться к данным при анализе структуры. И этот набор сильно зависит от данных. Поэтому надо предусмотреть этот набор и проверять каждое предполагаемое поле на соответствие ему.

Сообщение от DarkOrk По поводу хранения в "первичном" виде. В принципе да.. но... там была ещё подзадача, о которой я не сказал ввиду её неактуальности (если бы мы распарсили данные сразу). Нужно дать возможность изменять данные из клиента в бд.

Ничего страшного. Пусть данные ВСЕГДА хранятся в исходном формате. И только при показе пользователю, экспорте и обработке они должны приводиться к вещественному формату, редактироваться и обрабатыаться согласно своей природе, и затем корректно конвертироваться в тот формат хранения, который выбран для хранения в базе.

Сообщение от DarkOrk Если бы была таблица в завершённом её виде (в бд) то просто отобразив её в контроле для данных (DataGrid к примеру) мы б имели бы возможность обновить отредактированную строку через UPDATE, но храня нерасспарсеный вариант данных то придётся делать хранимую процедуру которая будет выполнять функции команды UPDATE (постоянно парсить все данные и по переданным параметрам искать и заменять значения), так?

Не хранимую процедуру, а метод на C#. Я бы для каждого типа данных сделал свой класс, который парсил бы исходные данные и делал обратную процедуру. Не надо уводить это в SQL. И не надо полагаться на датагрид. Но Вам наредактирует. Придётся ручками поработать. Чтобы дать юзеру возможность видеть и модифицировать данные в терминах предметной области. Кроме того не забывайте, что у каждой клетки свой ID. Датагрид сдохнет с этим работать. Он не для этого сделан.

1

Смотри:
-заливка данных в бд (понятно)
-табл. с метаданными (понятно; при заливке предварительный анализ и настройка с помощью узера)
-парсинг типов (скажем - понятно)
-получения данных в клиенте (понятно; преобразуем все данные согласно данным из мета таблицы)
-по поводу редактирования бд:
Идею я в принципе понял, то есть, по сути как можно сделать - распарсив данные в клиенте, сложить всё в 2 массива для хранения 2х состояний (исходного и отредактированного). Когда пользователь жмякнит но кнопулю СЕЙВ - анализируем 2 массива. Делаем из оригинального "новый который в оригинальном формате будет содержать изменения" и залить его в БД (просто перезаписав все данные в бд на входные данные).

Это всё отработает если у БД один юзер. Ну а мы предположим что клиентов работающих с БД от 1 и больше... а как тогда данные то редактировать. Вот мы по моей схеме действий дошли до пункта с перезаливкой данных, а во время нашей работы какой-то другой клиент изменил данные в таблице (может даже и метаданные). Идентификатор то легко сделать - дата последнего редактирования таблицы (и данных и метаданных).
А вот как дальше?? Что идти по шагам git-а? Кидать пользователю месадж с "ошибка миграции". Скачивать ещё раз данные из бд, снова парсить, делать сравнительную таблицу, мол "..это в БД удалено! хотите добавить?", а "эта колонка сменила тип данных, "...какой из сохранить?".
Или какой-то более простой вариант я из виду упускаю?

0

Сообщение от DarkOrk Или какой-то более простой вариант я из виду упускаю?

Да.
Делаешь табличку например DataUnderModifying(sessionID, ID_Type, ID_Data, LastActualTime). Юзер взял данные на редактирование - заносишь данные в эту таблицу. Для каждого редактируемого элемента данных. Пока не закончит - каждые например 10 секунд обновляешь поле LastActualTime с помощью GetDate() - временем сервера то есть.
Пусть у тебя джоба удаляет устаревшие записи из этой таблицы, например старше 20 секунд.
А когда другой юзер просит показать ему данные в клиенте - даёшь ему либо с полным доступом, либо в явном виде read only.

1

Суть понял. Чуть конкретнее о таблице под кодовым именем DataUnderModifying.
sessionID - какой нить идентификатор текущей операции редактирования
ID_Type - тип операции read/write
ID_Data - имя таблицы которая сейчас "под воздействием клиента"
LastActualTime - время когда эта операция последний раз дёргалась (Первый раз когда клиент её запросил и до тех пор пока не вернёт обновляем статус каждые 10 сек, если джоб находит строку с LastActualTime< (GetTime()-00:00:20) удаляем её.)

Клиент если просит таблицу - проверяем её наличие в DataUnderModifying и если статус write находим, то только readOnly возвращаем (ну и в клиенте можно авто абдейт сделать). Если не находит то ридОнли с возможностью включить редактирование.

Можно ещё колонку добавить LastModifyedTime, да бы клиент который в статусе ридОнли с автоАбдейтом не каждые 10 сек перезаливал данные, а только если его внутренний флаг LastUpdateTime отличается от LastModifyedTime.

Всё правильно пронял? Что то перепутал?

0

Сообщение от DarkOrk ID_Type - тип операции read/write

Это скорее про имя таблицы (данные / метаданные)

Сообщение от DarkOrk ID_Data - имя таблицы которая сейчас "под воздействием клиента"

А это идентификатор записи в таблице

Вероятность того, что два юзера будут одновременно править одни и те же данные гораздо меньше, чем вероятность того, что два юзера одновременно будут.

Сообщение от DarkOrk Можно ещё колонку добавить LastModifyedTime, да бы клиент который в статусе ридОнли с автоАбдейтом не каждые 10 сек перезаливал данные, а только если его внутренний флаг LastUpdateTime отличается от LastModifyedTime.

По уму это надо тогда в таблицу данных добавлять и в таблицу метаданных.

0

Хм, а как ты предлагаешь обновлять 1 запись в какой-то таблице? поскольку мы остановились на варианте хранения исходных данных в "исходном варианте", по даже редактируя одну запись, по окончанию манипуляций, нам понадобится залить всю таблицу (с одной изменённой записью), а юзеру (второму) забрать её, распарсить (снова, т.к. первый вариант у него уже на руках) и взять себе это изменение. Идентификатор у каждого картежа конечно же есть, но таблица в БД у нас (утрируя) это просто набор байтов (ну там это строка будет, но т.к. мы её парсим только в клиенте, то для БД это просто некие данные.

Я подумал а варианте таком:
-2 пользователя скачали таблицы.
-1й юзер начал редактировать запись. 2й юзер: запрашиваем права на редактирования всей таблицы: нет - то сообщаем о блоке; да - в таблицу по контролю за модификацией таблиц добавляем запись о клиенте в котором сейчас идёт работа (ну и редактируем) )
-1й юзер закончил редактирование - удаляем запись в таблице модификаций (тут получается джоб не на 20 сек нужен, а на 30-60 (в случае если давно ответа нет от клиента). Каждый клиент отчитывается о своём состоянии).

Блин... а это получается очень большой объём данных придётся обрабатывать из за одной записи. А как ты предлагаешь одну запись менять??
-Идентифицировать
-сохранить в бд в исходный формат таблицы
-получить одну запись, на втором клиенте, из таблицы в исходном формате.

0

Сообщение от DarkOrk нам понадобится залить всю таблицу (с одной изменённой записью)

Сообщение от DarkOrk а это получается очень большой объём данных придётся обрабатывать из за одной записи

Зачем? Можно обновлять только модифицироаванные записи.

Или ты думаешь, что юзер разом будет редактировать всю таблицу, а не её малую часть? Если таблица такая маленькая, к чему тогда всё это ?

Сообщение от DarkOrk А как ты предлагаешь одну запись менять?? -Идентифицировать -сохранить в бд в исходный формат таблицы -получить одну запись, на втором клиенте, из таблицы в исходном формате.

Я всё описал уже. Проведи выходной как следует, потом свежим взглядом посмотри, подумай ещё раз. Безо всакого overenginering. Ну простая же задачка-то.

0