Я только начинаю работать над библиотекой журналов, которую каждый может использовать для отслеживания любой системной информации, пока пользователь запускает наше приложение. Простейший пример на данный момент - это отслеживание информации, предупреждений и ошибок.
Я хочу, чтобы все плагины могли использовать эту функцию, но, поскольку у каждого разработчика может быть свое представление о том, что важно сообщать, я хочу сделать это как можно более универсальным.
В мире C ++ я обычно использовал бы что-то вроде stl::pair<string,string>, чтобы действовать как структура пары ключ-значение, и имел бы stl::list из них, чтобы действовать как "строка" в журнале. Тогда кеш журнала будет list<list<pair<string,string>>> (тьфу!). Таким образом, разработчики могут использовать строковый ключ const, такой как INFO, WARNING, ERROR, для согласованного именования столбца в базе данных (для выбора определенных типов информации).
Я бы хотел, чтобы база данных могла иметь дело с любым количеством различных имен столбцов. Например, у Джона может быть строка INFO со столбцом с именем USER, а у Билла может быть строка INFO со столбцом с именем FILENAME. Я хочу, чтобы средство просмотра журнала могло отображать всю информацию, и если в одном отчете нет значения INFO / FILENAME, эти поля должны просто отображаться пустыми. Таким образом, одним из вариантов является использование List<List<KeyValuePair<String,String>>>, а другим - заставить потребителя библиотеки журналов каким-либо образом «зарегистрировать» свою схему, а затем заставить базу данных выполнить ALTER TABLE для обработки этой ситуации. Еще одна идея состоит в том, чтобы иметь таблицу, предназначенную только для пар «ключ-значение», с внешним ключом, который отображает пары «ключ-значение» обратно в исходную запись журнала.
Я, очевидно, не хочу, чтобы журналирование перегружало систему, поэтому я блокирую только кеш журнала, чтобы сделать копию данных (и удалить уже скопированные данные), затем фоновый поток будет выгружать информацию в базы данных.
Мои конкретные вопросы по этому поводу:
- Видите ли вы проблемы с производительностью? Другими словами, вы когда-нибудь пробовали что-то подобное и обнаружили, что некоторые вещи просто не работают на практике?
- Существует ли более .NETish способ реализации пар ключ-значение, кроме
List<List<KeyValuePair<String,String>>>?
- Даже если есть способ сделать №2 лучше, идея ALTER TABLE, которую я предложил выше плохой вещи?
- Вы бы порекомендовали несколько баз данных по одной? У меня пока нет представления о том, как часто будет записываться журнал, но в идеале нам хотелось бы иметь много информации низкого уровня. Возможно, должна быть БД с фиксированной схемой только для вещей низкого уровня, а затем еще одна БД, более гибкая для предоставления информации пользователям.