ненужная нормализация

Мой друг и я создаем веб-сайт и у нас есть серьезные разногласия. Ядро сайта - это база данных комментариев о «людях». Обычно люди могут вводить комментарии и могут вводить человека, о котором идет речь. Затем зрители могут искать в базе данных слова, которые есть в комментарии или частях имени человека. Он полностью создан пользователем. Например, если кто-то хочет опубликовать комментарий к неверно написанному имени человека, он может, и это нормально. Таким образом, может быть несколько вариантов написания разных людей, перечисленных как несколько разных записей (некоторые с отчеством, некоторые с ником, некоторые с ошибками и т. Д.), Но это все нормально. Нас не волнует, комментируют ли люди случайных или воображаемых людей.

В любом случае, вопрос в том, как мы структурируем базу данных. Сейчас это всего лишь одна таблица с идентификатором комментария в качестве первичного ключа, а затем есть поле для «человека», о котором идет речь:

идентификатор комментария - комментарий - человек

1 - «он странный» »- Джон Смит

2 -« вонючая девушка »- Дженни

3 -« гей »- Джон Смит

4 -« Должен мне 20 долларов »- Jennyyyyyyyy

Все работает нормально. Используя базу данных, я могу создавать страницы, на которых перечислены все «комментарии» для конкретного «человека». Тем не мение, он одержим тем, что база данных не нормализована. Я прочитал о нормализации и узнал, что он ошибался. Таблица в настоящее время нормализована, потому что идентификатор комментария уникален и определяет «комментарий» и «лицо». Теперь он настаивает на том, чтобы у «человека» была СОБСТВЕННАЯ таблица, потому что это «вещь». Я не думаю, что это необходимо, потому что, хотя «человек» на самом деле является большим контейнером (у одного «человека» может быть много «комментариев» о них), база данных, кажется, работает нормально, когда «человек» является атрибутом идентификатор комментария. Я использую различные вызовы PHP для разных выборок SQL, чтобы он волшебным образом выглядел более сложным на выходе, и чтобы пользователь мог искать и видеть результаты по-другому, но на самом деле настройка довольно проста. Теперь я разрешаю пользователям ранжировать комментарии «палец вверх» и «палец вниз», и я сохраняю «счет» в другом поле той же таблицы.

Я считаю, что в настоящее время нет необходимости иметь отдельную таблицу только для уникальных записей «человек», потому что «люди» не имеют своей собственной «оценки» или каких-либо собственных атрибутов. Только комментарии. Мой друг настолько настойчив, что это необходимо для эффективности. Наконец, я сказал: «Хорошо, если вы хотите, чтобы я создал отдельную таблицу и позволил 'person' быть ее собственным полем, тогда что было бы вторым полем? Потому что, если таблица имеет только один столбец, это кажется бессмысленным. Я согласен что позже мы можем создать потребность дать "человеку" его собственный стол, но тогда мы сможем с этим справиться ". Затем он сказал, что строки не могут быть первичными ключами, и что мы преобразуем «лиц» в текущей таблице в числа, и эти числа будут первичным ключом в новой таблице «лиц». Мне это кажется ненужным и затрудняет чтение текущей таблицы. Он также считает, что позже будет невозможно создать вторую таблицу, и что сейчас нам нужно предвидеть, что она нам может понадобиться для чего-то позже.

Кто прав?