Thread ID's changed, links to your site no longer work?

[digitalpoint]

Yeah, I understand the reason why they can't be transitioned... I just had issue with the statement that it's "bad practice" to retain unique IDs when possible.

[sadikb]

Okay,

So a quick run down, is that in order to transition the system into the new db schema the new key ids don't really match their old counter parts.
We had things like postid, threadid, blogid, groupid, socialgroupmesageid, pmid, forumid, etc. these can't be carried over 1:1 into the new schema because of the schema.
We keep these old ids mapped properly. So if someone comes in via showthread.php?t=X or p=Y or forumdispay.php?f=Z they get redirected to the proper item in the new system.


Am I making more sense now?

Yes you are. It is a fallout of the single node table.

I think at the very least, threadids could have been preserved, and starting the numbering of other content types from where thread ids finish. This way about 80% of the redirect overhead could have been saved.

Overall I am not a huge fan of the schema with the single node table. I understand that a single table structure for different content types is a good thing, but overall there are the performance risks of querying for say a visitor message on a say, 20 million rows node table.

[ShyGuy82]

Zach, OR....there was another option for your developers. Have a combined primary key in the NODE table (I'm assuming it's called node). RecordId, ContentTypeId. This way you can easily map old Ids in the new system with this setup without storing OLD ids altogether. The only difference with this setup is that you no longer have auto-generated keys (you have to get Max(recordid) from node where contetypeid = X). But since new requirements for vB5 is MySql 5, they could use stored procedures, which cache sql statements a lot better than running them dynamically.

I really don't want to bash vBs developers but there is a HUGE difference between doing it right and doing it "anyway, as long as the functionality does what I want".

[Wayne Luke]

So does this mean that any links to my site that are posted on another site, could be directed to the wrong thread as the thread ID number changed?

Actually old links to your site should continue working and automatically link to the new URLs for items.

[Wayne Luke]

Zach, OR....there was another option for your developers. Have a combined primary key in the NODE table (I'm assuming it's called node). RecordId, ContentTypeId. This way you can easily map old Ids in the new system with this setup without storing OLD ids altogether. The only difference with this setup is that you no longer have auto-generated keys (you have to get Max(recordid) from node where contetypeid = X). But since new requirements for vB5 is MySql 5, they could use stored procedures, which cache sql statements a lot better than running them dynamically.

Aside from stored procedures, we're pretty much doing it like this. Stored procedures would be nice in the future though.

[Retal]

So - the heart of every forum - threads and posts - get renumbered.
And their URLs change.
And the redirect to the new ones is 302, Temporarily Moved.

No way we're ever upgrading.
You don't mess with my URLs, the backbone of my website.

[Alfa1]

Okay,

So a quick run down, is that in order to transition the system into the new db schema the new key ids don't really match their old counter parts.
We had things like postid, threadid, blogid, groupid, socialgroupmesageid, pmid, forumid, etc. these can't be carried over 1:1 into the new schema because of the schema.
We keep these old ids mapped properly. So if someone comes in via showthread.php?t=X or p=Y or forumdispay.php?f=Z they get redirected to the proper item in the new system.


Am I making more sense now?

Yes, this is completely logical. Except for the fact that part of the remapping can be avoided. Threads are by far the most linked to, so keeping that ID, would at least reduce the chance of issues and reduce the need for redirects for threads.

[ShyGuy82]

Aside from stored procedures, we're pretty much doing it like this. Stored procedures would be nice in the future though.

Wayne, I really really not trying to be negative but given the requirements for vB5 why wouldn't developers do that from the get go? Not only its a lot faster than dynamic sql, it also makes code maintenance so much easier. If something doesn't work right with the query - change it in one place, recompile stored proc and you are done. Stored procs also remove spaghetti string concatenation in code, it's a lot easier to read. They also give you full control of conditional coding, loops, cursors etc.

About old links - I understand that old links would still work because you guys store old Ids during the upgrade. The problem with this is that you store bloated records (they are unneeded). This extra column takes 4 bytes, with 1 million posts, that's extra 40MB. Multiply that number of records of ALL CONTENT and you get a lot of used space in the database (dead space). I haven't seen the code yet but I really hope vB doesn't store old Ids in the same node table. If they do, this bloated size will continue to grow even for new records. They would store 0 (zero) as old id and still take 4 bytes. Someone with larger boards than mine will increase their database size even more dramatically.

[Retal]

Even if vB emitted the correct HTTP code (301 instead of 302), can you imagine what such a huge amount of redirects does to the search engine rankings?
If 99% pages change their URL, the website can kiss its whole Google ranking goodbye for at least three months. A lot of them will most likely never return to their old positions.
This is an unbelievable decision.

I don't care that vB5 decided to go all Reddit on its database and use one huge "things" table. The URLs should, no, must not change.

[ShyGuy82]

Retal I've written a post in other thread (don't remember where) where I've explained that 301 is perfectly fine for google. I've done exactly that 2 weeks ago. Google reindexed all my links within a week (hundreds of thousands of them). Some old links still do show up in search results but it didn't hurt my ranking one bit, I would actually argue that I increased my search traffic since then.

[slinky]

Retal I've written a post in other thread (don't remember where) where I've explained that 301 is perfectly fine for google. I've done exactly that 2 weeks ago. Google reindexed all my links within a week (hundreds of thousands of them). Some old links still do show up in search results but it didn't hurt my ranking one bit, I would actually argue that I increased my search traffic since then.

Lucky you. I have seen numerous sites that have not had this experience. And then there is the issue of the overhead requiring you to map every single one of your posts/threads, etc. - let's say you have 500,000 posts.... what about 5 million? I avoided this entirely with VB 4. Right now, moving to any other software is the same as moving to VB 5. I'm not altogether confident of VB 5's direction at the moment.

[Retal]

301 is perfectly fine for google. I've done exactly that 2 weeks ago. Google reindexed all my links within a week (hundreds of thousands of them). Some old links still do show up in search results but it didn't hurt my ranking one bit, I would actually argue that I increased my search traffic since then.

Even if that were true - which it isn't - are you going to let vB change your links on every major version?
New links when upgrading to vB5, then new links when upgrading to vB6 (provided the company survives), etc?

It's simply a good practice not to change the URLs and vB has done the very opposite - changed *everything*.

See also Cool URIs don't change.

[Andy]

I would like to be able to have the upgrade program keep the threadid the same and the URL format be the same as I currently use which is the Standard URLs that I've used for the last 10 years. Example:

https://www.vbulletin.com/forum/showthread.php?t=407313

Don't tell me it would be impossible to do this.

[Zachery]

It is currently impossible to do. (because we haven't done it. I don't know how feasible it is to actually do, since there isn't a showthread.php file, i am not a modrewritefu master)

https://www.vbulletin.com/forum/showthread.php?t=407313

Would redirect to the new url format though

[Andy]

https://www.vbulletin.com/forum/showthread.php?t=407313

Would redirect to the new url format though

I will not upgrade if the threadid and postid are changed. I don't want to have to use a lookup table with millions of rows of data to convert old id's to new id's.