Announcement

Collapse
No announcement yet.

What is it with the Channel/Forum thing in vB5?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • What is it with the Channel/Forum thing in vB5?

    Due to personal interest: Can you give some more information/insight about the whole Channel/Forum thing in vB5? It seems a little inconsequent to me, if we have a "Channel Manager" in the AdminCP (and also "Edit Channels" there), but then are allowed to click a "Add new Forum" button. Then it is "Channel Permissions" again...

    Why did the designers decide to bring the word Channels in place at all? There are categories and forums, but what do we need channels for? Or does this follow some deeper system I haven't encountered yet?

  • #2
    Channel is all encompassing.

    Blogs are a channel.
    Categories are a channel
    Groups are a channel
    Forums are a channel
    No doubt articles will also be a channel.

    In theory it does away with separate database tables for everything (as in vB4).
    MARK.B | vBULLETIN SUPPORT

    TalkNewsUK - My vBulletin 5.5.2 Demo
    AdminAmmo - My Cloud Demo

    Comment


    • #3
      Hmm... I get the idea, but I still don't see a real advantage here. Is the database thing really a big issue? I mean, content still has to be stored in some way, right?

      Comment


      • #4
        Try running a cross-content intensive search in vB4 for example....
        MARK.B | vBULLETIN SUPPORT

        TalkNewsUK - My vBulletin 5.5.2 Demo
        AdminAmmo - My Cloud Demo

        Comment


        • #5
          I see...

          Well, I think I still have to get used to this.

          Comment


          • #6
            Originally posted by TLMD View Post
            Hmm... I get the idea, but I still don't see a real advantage here. Is the database thing really a big issue?
            Someone with even the most cursory knowledge of SQL will know that there is no benefit to shoving disparate data types into a wide "Swiss army knife" table that tries to do everything. In fact, there are mostly downsides to such an arrangement. Also, with all these different content types being in a single "all purpose" table, it makes for a nightmare should you ever wish to extract your data from vB5 and migrate it elsewhere. Customer lock-in?

            P.S. As usual, I had to copy-paste and use an outside editor as editing is impossible in this window.

            Comment


            • #7
              Originally posted by feldon23 View Post
              Also, with all these different content types being in a single "all purpose" table, it makes for a nightmare should you ever wish to extract your data from vB5 and migrate it elsewhere. Customer lock-in?
              There would be no reason exporting data would be any more difficult in a vb5 setup as opposed to vb4, A simple join statement can limit the content type being exported in any query.

              Comment


              • #8
                Originally posted by feldon23 View Post
                Someone with even the most cursory knowledge of SQL will know that there is no benefit to shoving disparate data types into a wide "Swiss army knife" table that tries to do everything. In fact, there are mostly downsides to such an arrangement. Also, with all these different content types being in a single "all purpose" table, it makes for a nightmare should you ever wish to extract your data from vB5 and migrate it elsewhere. Customer lock-in?.
                Someone with even the most cursory knowledge of SQL could extract the data quite easily, its nothing more than simple selects and joins (and "where" as required).
                Baby, I was born this way

                Comment

                Related Topics

                Collapse

                Working...
                X