Question

I want to agregate updates of my tables into a feed. Let´s take sample tables

News, User->[Info-Update, Friendships,
Images, Videos], SomeOtherTable

On every update or insert an event is fired.

Now there will be, for this different types, some handlers that should generate the feed.

Problem 1: FeedTable, its columns, localized titles and text.

My first idea.

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

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

My second idea, using Linq to Sql inheritance

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

Over this I would create some classes and i would then assign the column to the linqtosql classes. The problem is localization, so in this second approach I would “render” the stuff into the Feed so no manipulation or anything else would be performed, it would, as is, be directly bound to a control. As I said, I have columns, like title and text, that are localized, so i would have to make the “feed” table split up into more localized versions.

I need here some concept that is clear, maintainable, easy searchable. Any ideas? Is it clear what i want to achieve?

Answer 1

If your Feed and FeedDetails tables will have a 1:1 relationship between the records, and if both refer to the same conceptual object, then you can have them both in the same table. An unnecessary join will only complicate things, and can even degrade performance.

The localization won’t be 1:1, so it should be handled in a separate table, something like:

[TextKey] [RegionID] [LocalizedText]

where the PK is TextKey + RegionID, and TextKey maps back to your Feed table. I agree with @Thomas Rushton about using a View for this; you could also use a stored procedure, since you’ll be feeding it the RegionID along with a UserID and however many other parameters.

---

EDIT

Even if FeedDetails isn’t 1:1 with the Feed, you should give it its own table(s) with specific column names. There’s no particular advantage to using a name:value table; you’ll just add unnecessary joins, overhead, and complexity when you try to map the values back to a feed entry. More to the point, whenever possible, name:value tables should be avoided for the use you’re describing; relational databases are meant to use columns to describe data, and rows for its content. Finding what you’re looking for in a name:value table is going to be expensive and complicated. It will hurt performance a lot, because SQL will have to search through the name column every time you want to query it. You wouldn’t write a program where every variable was an untyped object in one huge array, so you shouldn’t do the same thing with SQL.

Also, I don’t see why the feed and feed details wouldn’t be 1:1. Even if there are optional parts like images, links, or attachments, you should use nullable fields for those if possible. Examine RSS feeds, which can optionally contain references to images or other data. If that would mean lots of nullable fields, you can normalize your database with tables like “Images” or “Links” or something. If you absolutely have to, you can use a supplemental XML “misc” column for any unanticipated special data. That’s to be avoided, but it’s still better than using a name:value table to avoid the tabular form that SQL is intended and optimized for.

You mention inheritance, but that’s not really relevant here. You have three conceptual objects in your example: A list of news entries, a localization map, and a user object. None of those objects has much in common with the others, nor any obvious potential as a base object, so there’s really no need for inheritance here. You don’t even need object composition, really, since none of them has a hierarchical data structure. You said “the problem is localization,” but you also said the localization table exists and works fine, and I don’t see why that should be an issue other than the join scheme I described.