Facebook, как канал

Question

Я хочу объединить обновления моих таблиц в ленту новостей.Давайте возьмем образцы таблиц

Новости, Пользователь -> [Инфо-обновление, Дружба, Изображения, Видео], SomeOtherTable

При каждом обновлении или вставке событияfired.

Теперь для этих разных типов будут некоторые обработчики, которые должны генерировать канал.

Проблема 1: FeedTable, его столбцы, локализованные заголовки и текст.

Моя первая идея.

One Table: "Feed" {date, type, title, ...}, 

Second Table "FeedDetails[]" {name, value}

Моя вторая идея, использующая наследование Linq to Sql

One Table: "Feed" {title, date, type, text, image1, 
                   image2, image3, imagecount, video, 
                   referenceId, referenceName, 
                   referenceId2, referenceName2, ... }

Для этого я бы создал несколько классов, а затем назначил бы столбец классам linqtosql.Проблема заключается в локализации, поэтому в этом втором подходе я бы «рендерил» материал в Feed, чтобы не было выполнено никаких манипуляций или чего-либо еще, так как он был бы напрямую связан с элементом управления.Как я уже сказал, у меня есть столбцы, такие как заголовок и текст, которые локализованы, поэтому мне придется разделить таблицу «feed» на более локализованные версии.

Мне нужна здесь какая-то концепция, которая понятна,ремонтопригодный, удобный для поиска.Есть идеи?Понятно, чего я хочу достичь?

Answer 1

Если ваши таблицы Feed и FeedDetails будут иметь отношение 1: 1 между записями, и если обе ссылаются на один и тот же концептуальный объект, вы можете иметь их обе в одной таблице. Ненужное объединение только усложнит ситуацию и может даже ухудшить производительность.

Локализация не будет 1: 1, поэтому она должна обрабатываться в отдельной таблице, что-то вроде:

[TextKey] [RegionID] [LocalizedText]

где PK - это TextKey + RegionID, а TextKey отображается обратно в вашу таблицу Feed. Я согласен с @Thomas Rushton об использовании View для этого; Вы также можете использовать хранимую процедуру, поскольку вы будете передавать ей RegionID вместе с UserID и многими другими параметрами.

---

EDIT

Даже если FeedDetails не 1: 1 с Feed, вы должны дать ему свою собственную таблицу (таблицы) с определенными именами столбцов. Нет особого преимущества в использовании таблицы name: value; вы просто добавите ненужные объединения, накладные расходы и сложность, когда попытаетесь отобразить значения обратно в запись фида. Более того, по возможности, следует избегать использования таблиц name: value для использования, которое вы описываете; реляционные базы данных предназначены для использования столбцов для описания данных и строк для их содержимого . Поиск в имени того, что вы ищете: таблица значений будет стоить дорого и сложнее . Это ухудшит производительность lot , потому что SQL придется искать в столбце name каждый раз, когда вы захотите запросить его. Вы не написали бы программу, в которой каждая переменная была бы нетипизированной object в одном огромном массиве, поэтому вы не должны делать то же самое с SQL.

Кроме того, я не понимаю, почему данные о подаче и подаче не будут равными 1: 1. Даже если есть дополнительные части, такие как изображения, ссылки или вложения, вы должны использовать для них пустые поля, если это возможно. Проверка RSS-каналов , которые могут содержать ссылки на изображения или другие данные. Если это будет означать множество полей, которые можно обнулять, вы можете нормализовать свою базу данных с помощью таблиц, таких как «Изображения» или «Ссылки», или что-то еще. Если вам абсолютно необходимо , вы можете использовать дополнительный XML-столбец «misc» для любых непредвиденных специальных данных. Этого следует избегать, но все же лучше, чем использовать таблицу name: value, чтобы избежать табличной формы, для которой предназначен и оптимизирован SQL.

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