Есть ли согласованная идеальная схема для меток

Я сделал это в маленькой системе без очень многих пользователей, но я задался вопросом прежде, если был "принятый" способ управлять тегами. После прочтения ссылок, отправленных insin и большим количеством других сообщений в блоге на метках, кажется, что принятый путь состоит в том, чтобы сохранить его полностью нормализованный и кэш определенные вещи, если Ваш набор данных становится слишком большим.

, Так как это - много-многие отношения (каждый тег может принадлежать любому количеству фотографий - каждая фотография может иметь много тегов), теория реляционной базы данных сделала, чтобы Вы составили фото таблицу, таблицу тега и таблицу перекрестных ссылок для соединения их.

photos
  photoid
  caption
  filename
  date

tags
  tagid
  tagname

phototags
  photoid
  tagid

Это имеет масштабирующиеся проблемы при выборе из действительно больших наборов данных, но также - все менее нормализованные схемы (сортировка и фильтрация по текстовому полю, вероятно, всегда будут медленнее, чем использование целого числа, например). Если Вы становитесь столь же крупными как восхитительными или возможно даже StackOverflow, необходимо будет, вероятно, сделать некоторое кэширование наборов тегов.

Другой проблемой, с которой необходимо будет столкнуться, является проблема нормализации тега. Это не имеет никакого отношения к нормализации базы данных - она просто удостоверяется, что (например), "StackOverflow", "stackoverflow" и теги "переполнения стека" являются тем же. Много мест запрещает пробел или автоматически разделяет его. Иногда Вы будете видеть то же самое для пунктуации - делающий "StackOverflow" то же как "Переполнение стека". Автопечатание строчными литерами является довольно стандартным. Вы будете даже видеть нормализацию особого случая - как создание "c#" то же как "до-диез".

Счастливые метки!

Что-то вроде этого прибывает по моему мнению: добавьте те две таблицы

Теги

• TagID
• TagName
• TagDescription

PhotoTags

• PhotoID
• TagID

Можно расширить это до альбомов также, имея перекрестную таблицу между Фотоальбомами и Тегами.

Я предлагаю надеяться видеть, как установленное программное обеспечение с открытым исходным кодом делает это. Например, Галерея хранилища ее метаданные в базе данных как Вы делают, и довольно богато.

я не думаю, что Вы найдете "стандартную" схему, все же. Самой близкой вещью, о которой я могу думать, является формат метаданных EXIF, который встраивается в самих файлах изображений (камерами, и т.д.).

если Вы хотите реальную производительность с миллионами записей, Вы могли бы сохранить теги в одном поле, разделенная запятая и получить записи с полнотекстовым демоном индекса/поиска как sphinxsearch. Все, что необходимо добавить, таблица, перечисляющая все теги со значением количества для знания, как часто они присоединены к объекту.

я знаю, что это не обычный путь и немного более сложный, чем чистое решение для базы данных, но это действительно действительно быстро для поиска связанных с тегом объектов.

Вы могли использовать полнотекстовый поиск fonctionnality Вашего механизма базы данных также, но когда существует много записей, большинство механизмов имеет тенденцию быть медленным.

, Если это для маленького проекта, можно пойти путем, швы хороший и надлежащий способ сделать. Но я просто совместно использовал бы с Вами это другое решение. О чем Вы думаете?

Быстрое примечание по тому, как обработать теги:

системы меток могут варьироваться от очень твердо определенных тегов, где создающие новые требуют явной дополнительной работы (думайте Gmail) к очень свободным системам, где добавление как можно больше тегов поощряется (думают flickr, или отмечающий звуковое содержимое, где запись может быть применена непосредственно как теги).

В целом, легко индексируемые медиа (текст!) должен иметь более твердую систему, так как само содержание теги - дополнительные теги существуют больше для классификации только. Медиа это более трудно индексировать (изображения, видео) должен иметь гибкую систему, которая поощряет много тегов, так как они - Ваша единственная надежда при поиске.

Это важно, потому что схема базы данных, которую Вы хотите, могла измениться несколько, в зависимости от которого конца того спектра Вы оказываетесь.

В моем приложении BugTracker.NET я делаю предположение, что не будет Слишком многих ошибок. Возможно, десятки тысяч, но не десятки миллионов. То предположение позволяет мне кэшировать теги и идентификаторы объектов, на которые они ссылаются.

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

то, Когда поле метки добавляется или изменяется, который начинает фоновый поток, который выбирает весь bugids и их теги, анализирует текст, создавая карту, где ключ является тегом, и значение является списком всех идентификаторов, которые имеют тот тег. Я затем кэшируюсь, которые отображаются у Asp. Объект Сетевого приложения.

Ниже код, который я только что описал.

код мог быть оптимизирован так, чтобы вместо того, чтобы пройти все ошибки он просто инкрементно изменил кэшируемую карту, но даже неоптимизированный, он хорошо работает.

, Когда кто-то делает поиск с помощью тега, я ищу значение в карте, получаю список идентификаторов и затем выбираю те ошибки с помощью SQL с "где идентификатор в (1, 2, 3...)" пункт.

    public static void threadproc_tags(object obj)
    {
        System.Web.HttpApplicationState app = (System.Web.HttpApplicationState)obj;

        SortedDictionary<string,List<int>> tags = new SortedDictionary<string,List<int>>();

        // update the cache
        DbUtil dbutil = new DbUtil();
        DataSet ds = dbutil.get_dataset("select bg_id, bg_tags from bugs where isnull(bg_tags,'') <> ''");

        foreach (DataRow dr in ds.Tables[0].Rows)
        {
            string[] labels = btnet.Util.split_string_using_commas((string) dr[1]);

            // for each tag label, build a list of bugids that have that label
            for (int i = 0; i < labels.Length; i++)
            {

                string label = normalize_tag(labels[i]);

                if (label != "")
                {
                    if (!tags.ContainsKey(label))
                    {
                        tags[label] = new List<int>();
                    }

                    tags[label].Add((int)dr[0]);
                }
            }
        }

        app["tags"] = tags;

    }