Станислав Макаров

Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.

Можно попробовать абстрагироваться на уровне ORM, если таковой есть - т.е. объекты одних классов извлекаются через одно подключение к БД, другие - через другое. Если SQL-запросы пишете сами, то и думать нечего - структириуете код, как считаете естественным, и где-то в каком-то классе или контроллере (например, Logger) храните в поле необходимое подключение к БД. В другом модуле/классе - другое.

То, что у вас есть - это EAV-моделька. То, что вы хотите с ней сделать - превратить в обычное отношение - вполне можно назвать Pivot.
Вот тут SO подоспел с советами, как раз по вашей части, включая MySQL:
stackoverflow.com/questions/8764290/what-is-best-p...
stackoverflow.com/questions/649802/how-to-pivot-a-...

Толк от вызова метода Dispose есть всегда, когда есть сам метод Dispose (а если быть точным - если реализован интерфейс System.IDisposable). Тут просто не ваша ответственность разбираться - нужно ли вызывать Dispose или нет. Если автор класса реализовал этот интерфейс, значит для чего-то это ему нужно. Как правило это нужно, если используются управляемые вручную ресурсы (например, открытые файлы), либо в объекте создаются другие объекты, которые также IDisposable, и они должны подчищаться при disposing-е основного объекта, их создавшего.
Если вы сталкивались с С++, то на мой взгляд Dispose - это и есть настоящий "деструктор" для объекта, который нужно вызывать самому (прямо или косвенно, с помощью using), чтобы корректно завершить жизненный цикл объекта. Так или иначе, вызывайте Dispose всегда, когда завершаете взаимодействие с объектом. Важно, что даже если СЕЙЧАС в реализации этого метода особо ничего не происходит, функционал может быть добавлен ПОЗДНЕЕ, в новой версии библиотеки которую вы используете. И тогда вам придется исправлять ваш код, чтобы избежать утечки ресурсов (незакрытые файлы или коннекции к БД часто гораздо бОльшая проблема, чем подтекающая память).