Одиночный столбец против многоколоночного дизайна (для столбцов без первичного ключа)

В общем, наличие дискретных столбцов - лучший способ пойти по нескольким причинам:

1. Типы данных. У вас есть гарантии, что сохраненные вами данные находятся в правильных форматах, по крайней мере, до тех пор, пока не будут столбцы, отличные от строки, ваш запасной номер всегда будет числом, если он имеет значение bigint/long, пытаясь установить его на что угодно, ваша вставка/обновление до ошибки. Как часть строки с разделителем двоеточия (CSV) существует вероятность появления плохих данных, когда она является частью строки.

2. Querying - запрос одного столбца должен выполняться с использованием LIKE поскольку вы ищете подстроку одной строки столбца. Если я ищу WHERE StockDetails LIKE '%11111%' я найду первую строку, но я могу найти другую строку, где значение доллара внутри этого столбца в другом поле равно $ 11111. С дискретными столбцами ваш запрос будет WHERE StockNumber = 11111 гарантирующий, что он найдет данные только в этом столбце.

3. Использование данных. После того, как вы нашли нужную строку, вам необходимо прочитать данные. Это означает разбор CSV на отдельные поля. Если в одном из этих полей есть двоеточие, и это неправильно экранировано, остальные данные будут проанализированы неправильно, и вам все равно понадобятся ваши значения в том же порядке, оставив пустые разделы ;; где у вас было бы нулевое значение в столбце.

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

+--------------------------------------+
|             StockDetails             |
+--------------------------------------+
| {"number":11111, "domain":"Finance"} |
| {"number":23458, "domain":"Medical"} |
+--------------------------------------+

Это решает проблемы 2 и 3 выше:

2. Теперь вы пишете свой запрос как WHERE StockDetails LIKE '%"number":11111 включая имя свойства json, гарантирует, что вы не найдете данные нигде в своей строке.
3. Вам не нужно беспокоиться о том, что поля вышли из строя или отсутствуют в вашей строке, из-за чего ваши данные будут непригодными для использования, поскольку json дает вам пару ключ/значение, все, что вам нужно сделать, это обработать нули, где ключ не существует, Это также позволяет легко добавлять поля, добавляя новое поле CSV, чтобы разбить ваш код на синтаксический анализ, количество значений будет отключено для ваших существующих данных, поэтому вам нужно будет обновлять все строки потенциально, однако, поскольку в json вы только сохраняете non null fields, новое поле будет рассматриваться как любое другое нулевое значение для существующих данных.