Наивным способом было бы поместить весь путь в БД в виде строки, и это сработало бы для игрушечных БД. Однако такой подход дает ненормализованную БД.
Кто тебе это сказал? Это самая нелепая вещь, которую я слышал за долгое время. Избавьтесь от них, как только сможете, и не платите им за такие абсурдные «советы».
Короткий ответ
Это так же абсурдно, как сказать: если вы храните номера телефонов или адреса в базе данных в необработанном виде, это наивно и не нормализуется.
Поместите ваши URL в один столбец в базе данных (верхний или нижний конец). Это не нарушает правила нормализации. (Предполагая, конечно, что база данных нормализована в других отношениях.)
Длинный ответ
Давайте рассмотрим два контрапункта.
Некоторые люди не понимают, что Нормализация - это принцип . Конечно, при применении этого принципа в базах данных у нас есть нормальные формы, и вы либо соблюдаете нормальные формы, либо нарушаете их. Но это не весь принцип. Вы также можете легко получить шокирующую базу данных, потому что она не нормализована, даже если она может быть в 3NF.
Допустим, у вас есть таблица Customer с набором столбцов, которые составляют «адрес». И таблица Поставщика, которая также имеет те же (мы надеемся, точно такие же) столбцы, которые составляют «адрес». До тех пор, пока функциональные зависимости разрешены, это правильно, и нет ничего, кроме нормальных форм, которые идентифицируют, что они не соответствуют 3NF или 5NF. Такая база данных будет в порядке. Но хороший дизайнер (в отличие от квалифицированного, но неопытного) нормализует столбцы «адреса» в отдельной таблице адресов и помещает для нее FK в таблицы Customer и Supplier. Этот конструктор предоставляет вам более Нормализованную базу данных, которую еще проще поддерживать, но она все еще находится в той же 3NF или 5NF, что и раньше.
Новичку нормализаторам нужно нормализовать все. Они забывают цель базы данных и нормализуют до степени, которая за ее пределами. По тому же рассуждению человека, который сказал вам, что столбцы «адрес» и содержимое этих столбцов «не нормализованы». Пока у вас есть Washington St, Washington Blvd, Washington Lane, Holy Moley, «это наивно и база данных не нормализована». Абсолютная чепуха.
Для целей большинства баз данных вполне достаточно хранения названия улицы и типа улицы в одном столбце. И если бы у вас был хороший дизайнер, убедитесь, что он реализовал бы отдельную таблицу адресов. Многочисленные вхождения «Вашингтон» в названиях улиц нельзя назвать «дубликатами». Но если бы вы были городским советом или коммунальным предприятием, у вас была бы другая цель , в этом случае это было бы недостаточно хорошо, и да, там вы бы нормализовали группу столбцов "адрес" к В-третьих, такие «Вашингтон» или «Улица» никогда не повторяются в качестве значения данных. И для этого нужен очень опытный дизайнер. Только для небольшого меньшинства с другой целью.
Поэтому, если ваша база данных имеет цель тщательного анализа всего содержимого URL-адресов и восстановления представления в виде дерева или стиля проводника, то непременно создайте структуру каталогов в таблицах, что позволяет хранение каждого компонента URL и иерархии, и никогда не дублировать какой-либо компонент. Но если ваша цель просто хранить URL-адреса, как большинство людей хранят адреса или номера телефонов, то просто храните необработанные URL-адреса, такие как адреса или номера телефонов. Вы можете выполнять вполне разумные поиски и сопоставлять составные части необработанного URL-адреса, находить файлы MP3 или что-либо подобное.
Нет «лучшего» без измерения критериев.Не существует универсального подхода.База данных по электроэнергетике "слишком сложна" (слишком нормализована) для большинства целей;обычная база данных "неадекватна" для электроэнергетики.Если вы определили цель, типы поисков, которые вам требуются, которые определяют критерии, по которым можно измерять «лучшие», «лучшие» или «неудачные».
Ответ на комментарии
Ваш Редактировать изменил ландшафт.Хотя обычный уровень нормализации может быть адекватным уровнем для большинства людей (поэтому он не является «наивным»), вам нужно нечто большее, вы ближе к электросети, вам нужна структура нормализованного каталога для хранения URL-адресов или полных путей,и вам нужно удалить дублирование из значений данных .Например./var, /www, /sites и т. Д. Сохраняются один раз.
Нормализованный каталог
Нет проблем.Это тоже было сделано много раз.Я опубликовал точное требование в другом ответе .
Будьте уверены, что структура точная работает на двух больших серверах класса предприятия и что generic структура работает практически в каждой базе данных SQL, которую я написал более 25 лет.Это может выглядеть сложно, но как только вы обдумаете это, это будет просто и гибко.Допускается полная рекурсия и т. Д.
Вы можете задать вопросы в комментариях здесь.