Вот 1 нф говорит: Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

Т.е. структуру в которой

id | field

1 | 1,2,3,4,5
2 | 1,2,3
Это надо нормализовать в вид

id | id_field | field

1 | 1 | 1
1 | 2 | 2
1 | 3 | 3
1 | 4 | 4
1 | 5 | 5
2 | 6 | 1
2 | 7 | 2
3 | 8 | 3

А находиться ли таблица в 1нф если есть поле json?

id | field

1 | {'a':1,'b':2,'c':3,'d':4,'e':5}
2 | 1,2,3

_____________
Трус не играет в хокей

нет

вот так да

1 | {'a':1,'b':2,'c':3,'d':4,'e':5}
2 | 1
2 | 2
2 | 3

хотя первая строка...

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

stump, нормальная форма не для "мебели" или "красивых глаз".
Нормальная форма для того, что бы СУРБД могла работать (обрабатывать) на своём уровне по средствам языка SQL хранящиеся в БД данные.

_____________
Стимулятор ~yoomoney - 41001303250491

Поддержу Valick, добавив, что

WHERE field condition_operator value

Проблемотично (мягко говоря) будет сравнивать JSON строки

_____________
[продано копирайтерам]

Причём тут php. Речь идёт о субд
потом к примеру-тебе надо удалить все строки с 2? Как те тут php поможет?

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Ну а может, у него это поле с JSON не участвует в логике? Просто информационное, только читается и изменяется.
Тогда данный формат вполне имеет право на жизнь.

Я вообще прозрел в базах, когда пришлось жестко препарировать интернет-шоп. OsCommerce.
На мой взгляд, там суперская база.
Не, теорию я и до этого знал и что-то там релеционил, но вот отличное понимание пришло именно после нее. Рекомендую поколупать.

Грубо говоря, рассуждения бы шли так:
Есть товар. Значит таблица товара с полями цена, название, описание. (id по умолчанию везде есть)
Есть таблица позиций заказов. ну, тут все просто - id товара, количество товара, id заказа.
Стоп! А если я в будущем переименую товар, то клиент в своей истории покупок увидит уже совсем другое название. А если поменяю цену? Да, таблица позиций заказа должна быть денормализованой.
id товара (для статистики), наименование товара, цена, по которой клиент товар купил.

эээ.. а статистика по ценам?
Ведь, если меняю цену на товар, то теряется предыдущая цена.
ок, лепим еще одну таблицу с историей цен.
Хм, а зачем тогда вообще поле цена в таблице товара? Можно же из таблицы истории цен брать последнюю цену для данного товара.
Но тогда придется запрос к 2м таблицам.
И вот тут нет правильного и неправильного пути, должен сам решить, что для тебя важнее.
Повторяющееся поле в двух таблицах (запросы будут шустрее) или читать цену из таблицы истории цен (нет дублирующихся данных)

И т.д.

И вот, например, для таблицы позиций заказа, вполне бы подошло поле с JSON, чтобы кучу полей не городить, все равно они только для чтения и поиск по ним никогда не будет вестись.

_____________
[продано копирайтерам]

stump
Отношение 1:1 - это денормализация, нужна в исключительных случаях.
Если тебе денормализация не нужна, то все поля второй таблицы, связанной 1:1 просто могут быть расширением первой таблицы.

_____________
[продано копирайтерам]

stump, если тебе нужно работать в БД с JSON, то возьми нормальную БД, PostgreSQL. Не надо пытаться заставлять Мускуль делать то, для чего он не предназначен.

И вот почитай на досуге: http://www.postgresql.org/docs/9.3/static/...tions-json.html и это http://www.postgresql.org/docs/9.4/static/datatype-json.html

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)