Comment On The Homegrown CMS

"Axillary" code module? I love it, and will definitely begin using the expression.

I once saw someone try and make an important CMS in Lotus Notes. WTF
Another was a company that tried making their shrinkwrap very multi tier system in Lotus Notes. WTF

I loved VB6 in the day for knocking off little exe's that did something like a simple engineering calculation. Beyond that it was overwhelmed. So many products like VB6, Powerbuilder, Lotus Notes, etc promised the world but resulted projects permanently stuck at the 90% mark.

>Boolean-type values in the database were rendered as a CHAR(5) field holding possible values of 'true', 'false', or NULL.

He must have been burned in the past by MySql's crazy syntax to store and retrieve booleans in a BIT(1) type field.

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

> deleted in-line SQL where ever he found it

Also just his personal preference. Having in-line SQL isn't necessarily bad - depending on the application and how it's implemented.

TRWTF is that this is par for the course in a lot of places.

The real WTF is that he took the job in the first place. That should have raised massive red flags.

Fred, did you write this?

Porsche Oxter:

"Axillary" code module? I love it, and will definitely begin using the expression.

Yes, it means the code smelled like a sweaty armpit.

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

Fred, don't ever use "well designed" and "VB6" in the same paragraph again, unless you're include one of the following words:
wasn't
not
joke
fail

TRWTF is the CHAR(5) boolean field. It should have been at least CHAR(9) to hold "FILENOTFOUND".

Err, uh, make that at least CHAR(12) to hold "FILENOTFOUND".

Mike M:

...Or even any auto-incrementing IDENTITY columns for that matter...

I'd say having this feature is more of a WTF.

frits:

Mike M:

...Or even any auto-incrementing IDENTITY columns for that matter...

I'd say having this feature is more of a WTF.

Not if there is no natural unique identifier to be used although that is rare and usually indicates something that could be implemented better.

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

No, no it isn't.

Been there, supported that, quit 2 years ago. Thanks for ruining my Monday with my memories!

captcha:amet -> Amet preacher man Amet!

pete:

frits:

Mike M:

...Or even any auto-incrementing IDENTITY columns for that matter...

I'd say having this feature is more of a WTF.

Not if there is no natural unique identifier to be used although that is rare and usually indicates something that could be implemented better.

Really? I'm a big fan of surrogate keys. Looking through some of the databases I am responsible for, most of the tables in them have no natural unique identifier. What would you suggest a natural identifier for an order header record would be?

I wonder if the narrated version of these posts leave in all the spelling/grammar mistakes.

Jaime:

pete:

frits:

Mike M:

...Or even any auto-incrementing IDENTITY columns for that matter...

I'd say having this feature is more of a WTF.

Not if there is no natural unique identifier to be used although that is rare and usually indicates something that could be implemented better.

Really? I'm a big fan of surrogate keys. Looking through some of the databases I am responsible for, most of the tables in them have no natural unique identifier. What would you suggest a natural identifier for an order header record would be?

You're replying to a person who has obviously been through half a semester of DB Design 101.

Even if a record has a natural unique identifier, that natural unique identifier is most often a string (because that's how we humans think: in words). Strings suck for joining, selecting, and indexing on, because the compare takes an order of N longer than comparing an integer.

Sounds like the first iteration of DotNetNuke?!?!?

Anon:

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

No, no it isn't.

Ok, why it the design poor? It has a reasonable name, and actually uses parameters instead of global variables. Ok, the FreeFile thing is a red herring, but other than that it does what it has to do. Blame Bill Gates for the error handling weird syntax.

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

Oh, I totally agree! Misleading function names are so much fun --- when someone calls FileExists() and it returns "false" because the file really does exist but couldn't be opened for any other reason (permission, sharing, quota, etc.) you get to watch him go insane.

Crabs:

Jaime:

pete:

frits:

Mike M:

...Or even any auto-incrementing IDENTITY columns for that matter...

I'd say having this feature is more of a WTF.

Not if there is no natural unique identifier to be used although that is rare and usually indicates something that could be implemented better.

Really? I'm a big fan of surrogate keys. Looking through some of the databases I am responsible for, most of the tables in them have no natural unique identifier. What would you suggest a natural identifier for an order header record would be?

You're replying to a person who has obviously been through half a semester of DB Design 101.

Even if a record has a natural unique identifier, that natural unique identifier is most often a string (because that's how we humans think: in words). Strings suck for joining, selecting, and indexing on, because the compare takes an order of N longer than comparing an integer.

Surely not once indexed? There should be a negligible difference as far as I know. Not talking tables with millions of records here obviously.

You've never had a natural identifier change on you? There are very few cases where a surrogate key should not be used.

On a related note, I'm always amazed when I read the comments on the article. It makes me wonder how many WTFs the readers of the blog are creating for future generations to scratch their heads over.

Fred:

Anon:

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

No, no it isn't.

Ok, why it the design poor? It has a reasonable name, and actually uses parameters instead of global variables. Ok, the FreeFile thing is a red herring, but other than that it does what it has to do. Blame Bill Gates for the error handling weird syntax.

Public Function FileExists(sFullPath As String) As Boolean

    Dim oFile As New Scripting.FileSystemObject

    FileExists = oFile.FileExists(sFullPath)

End Function

Ike:

Err, uh, make that at least CHAR(12) to hold "FILENOTFOUND".

No, CHAR(9) is now the documented way of doing it. Besides, it's much more in the spirit of the thing. Correctness? Tried it, didn't like it.

Captcha: eros - yes, I like CHAR's very much for booleans.

Craig:

You've never had a natural identifier change on you? There are very few cases where a surrogate key should not be used.

On a related note, I'm always amazed when I read the comments on the article. It makes me wonder how many WTFs the readers of the blog are creating for future generations to scratch their heads over.

That's a feature, not a bug!

This is the worst WTF story in a while

Tom:

This is the worst WTF story in a while

Yeah, but it's the best one today.

Cyrus:

Fred:

Anon:

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

No, no it isn't.

Ok, why it the design poor? It has a reasonable name, and actually uses parameters instead of global variables. Ok, the FreeFile thing is a red herring, but other than that it does what it has to do. Blame Bill Gates for the error handling weird syntax.

Public Function FileExists(sFullPath As String) As Boolean

    Dim oFile As New Scripting.FileSystemObject

    FileExists = oFile.FileExists(sFullPath)

End Function

LOL pwned

Cyrus:

Fred:

Anon:

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

No, no it isn't.

Ok, why it the design poor? It has a reasonable name, and actually uses parameters instead of global variables. Ok, the FreeFile thing is a red herring, but other than that it does what it has to do. Blame Bill Gates for the error handling weird syntax.

Public Function FileExists(sFullPath As String) As Boolean

    Dim oFile As New Scripting.FileSystemObject

    FileExists = oFile.FileExists(sFullPath)

End Function

While that is a more succint method, the one in the article is very similar to the "C" way of checking of a file exists. Except for the superfluous "on error" statement, that is.

BTW- Nice 2 second googling, but you should set oFile to Nothing before exiting your function.

Craig:

You've never had a natural identifier change on you?

ON UPDATE CASCADE

Jaime:

I'm a big fan of surrogate keys. Looking through some of the databases I am responsible for, most of the tables in them have no natural unique identifier. What would you suggest a natural identifier for an order header record would be?

I'm a big fan of natural keys. But I heartily agree that when there is no obvious natural key, don't try to force one. I've seen crazy keys like "customer zip code plus bith date plus first three letters of last name". Like, give it up man! Just use a sequence number! I'm especially annoyed with db designers who put together some crazy collection of fields in the hope that it will be unique, and then tack on a sequence number because they know duplicates are possible. If you're going to put a sequence number on the end anyway, why not just forget the rest and just use the sequence number?

That said, when there is an obvious natural key, like "social security number" for employee or "two-letter state abbreviation" for a U.S. state, I'd prefer to just use it. Then I don't need a bunch of extra joins to get a recognizable identifier.

<comment type=grammar subtype=nazi>
"largely because writing applications are boring"

I think that should be, "writing applications IS boring". Just because applications is plural doesn't mean that the sentence calls for a plural verb. The subject of the verb is "writing", not "applications".

I usually brush off the grammar errors but for some reason this was leaped out and attacked me.
</comment>

[quote]
Boolean-type values were represented as a CHAR(5) field, holding possible values of 'true', 'false', or NULL.
[quote]

Ah, the luxury of a single fixed boolean representation (even with NULL).

My last job had a DB which represented booleans based on the preferences/ability/experience of the last programmer to check in a SQL update script.

So we had VCHAR2(256) or NUMBER(1,0) - and various sizes in between - columns with "TRUE"/"FALSE", "true"/"false", "T"/"F", "t"/"f", "YES"/"NO", "yes"/"no", "Y"/"N", "y"/"n", "1"/"0" or 1/0, with NULL scattered in there depending on whether the programmer had heard of NOT NULL.

Fred, don't ever use "well designed" and "VB6" in the same paragraph again, unless you're include one of the following words:
wasn't
not
joke
fail

I have seen VB6 used to create a well-designed application. This is no joke - and wasn't a failure.

Grammar Nazi:

I wonder if the narrated version of these posts leave in all the spelling/grammar mistakes.

I wonder if his please for help were ignored because he didn't say pleas.

Cyrus:

Public Function FileExists(sFullPath As String) As Boolean

    Dim oFile As New Scripting.FileSystemObject

    FileExists = oFile.FileExists(sFullPath)

End Function

Having been a VB programmer "back in the day" I will say that this was a much better way to check a file BUT you had to depend on VB Script being installed on the host PC. For a CMS running on a server, that would be fairly easy to do.

Jay:

Jaime:

I'm a big fan of surrogate keys. Looking through some of the databases I am responsible for, most of the tables in them have no natural unique identifier. What would you suggest a natural identifier for an order header record would be?

I'm a big fan of natural keys. But I heartily agree that when there is no obvious natural key, don't try to force one. I've seen crazy keys like "customer zip code plus bith date plus first three letters of last name". Like, give it up man! Just use a sequence number! I'm especially annoyed with db designers who put together some crazy collection of fields in the hope that it will be unique, and then tack on a sequence number because they know duplicates are possible. If you're going to put a sequence number on the end anyway, why not just forget the rest and just use the sequence number?

That said, when there is an obvious natural key, like "social security number" for employee or "two-letter state abbreviation" for a U.S. state, I'd prefer to just use it. Then I don't need a bunch of extra joins to get a recognizable identifier.

Except that SSNs are NOT unique!

It's hard to come up with a natural identifier which is stable. (Think zipcode or telephone number--what happens when you go global?) What's worse, many of the things which ought to work (SSNs, City+State) DON'T.

In case anyone misses it, the problem with max+1 indexing (aside from races) is that the final element might be deleted. If the deletion is incomplete, the orphaned pointers will point to the next record to be created.

Buffled:

Fred, don't ever use "well designed" and "VB6" in the same paragraph again, unless you're include one of the following words:
wasn't
not
joke
fail

I have seen VB6 used to create a well-designed application. This is no joke - and wasn't a failure.

Was it called "Hello World!"?

I like the poor grammar. When I saw, "the company had portal driven by a VB6 application", I envisioned a drive by shooting via portals. So, it classic XKCD styling, I made the following:

Marc B:

Grammar Nazi:

I wonder if the narrated version of these posts leave in all the spelling/grammar mistakes.

I wonder if his please for help were ignored because he didn't say pleas.

Give plia's a chance.

Cyrus:

Fred:

Anon:

Fred:

>The code module contained such gems as this function:
> Function FileExists(f As String) As Boolean

That one is actually well designed - it just looks sucky because of the way you had to do things in VB.

No, no it isn't.

Ok, why it the design poor? It has a reasonable name, and actually uses parameters instead of global variables. Ok, the FreeFile thing is a red herring, but other than that it does what it has to do. Blame Bill Gates for the error handling weird syntax.

Public Function FileExists(sFullPath As String) As Boolean

    Dim oFile As New Scripting.FileSystemObject

    FileExists = oFile.FileExists(sFullPath)

End Function

That wouldn't had worked in older versions of VB, which probably was the case with this CMS from hell. Not that it takes away from the fact the function in the article is really not that good (starting with the name, which actually tests for file accessibility, not existence.)

Oh well.

barry:

Crabs:

Jaime:

pete:

frits:

Mike M:

...Or even any auto-incrementing IDENTITY columns for that matter...

I'd say having this feature is more of a WTF.

Not if there is no natural unique identifier to be used although that is rare and usually indicates something that could be implemented better.

Really? I'm a big fan of surrogate keys. Looking through some of the databases I am responsible for, most of the tables in them have no natural unique identifier. What would you suggest a natural identifier for an order header record would be?

You're replying to a person who has obviously been through half a semester of DB Design 101.

Even if a record has a natural unique identifier, that natural unique identifier is most often a string (because that's how we humans think: in words). Strings suck for joining, selecting, and indexing on, because the compare takes an order of N longer than comparing an integer.

Surely not once indexed? There should be a negligible difference as far as I know. Not talking tables with millions of records here obviously.

Integers tend to be smaller than strings, requiring fewer bytes to be compared to find an exact match. Though you're correct that in a small database this would be negligible, you have to take into account that it will be difficult (possibly dangerous) to switch to a surrogate key later if the database use grows. Other issues to take into account revolve around using indexing...

First, you have to deal with index fragmentation on MSSQL. Since this is a string, you're probably going to want to put the FillFactor to 30 to give the server extra space to swap the indexes' order around on every INSERT. Of course, things are going to fragment anyways, so the second thing you're going to have to do is include this index in a regular rebuild/reorganize process. Third, this will have to be a unique key, so every time you do an insert the database will have to do string comparisons to make sure it doesn't exist already. Of course, the same is true of numbers, but they are smaller so the comparisons take less time/effort. (This type of comparison also gets multiplied if you have replication servers.) Then you have the worst case scenario: what happens when management decides they don't want your natural key to be unique anymore?

All-in-all, it's typically safer and faster to use an identity for your surrogate key from the beginning. There are times when I wouldn't do it, but for most tables I find it is better to take the small disk-usage hit this costs for the processing and maintenance reductions it returns.

Jay:

<comment type=grammar subtype=nazi>
I usually brush off the grammar errors but for some reason this was leaped out and attacked me.
</comment>

I refer you to http://en.wikipedia.org/wiki/Muphry%27s_law

Someone mentioned a home grown CMS in Lotus Notes.

During a gap year while doing my degree I was tasked to do exactly that...a CMS in Lotus Notes 3...

Scarred for life I am.

Actually I might even have the code somewhere - VBox, Win 3.1 installation and I reckon I could get it running again and post it here - on the other hand there *are* moral limits to the sort of suffering that one can cause and ensure oneself too...

Imagine what happens should two people run the same report at the same time.

What a mind blowing concept! Two people using the same thing! At the same time even!

We still have a lot of people who can't wrap their brains around the idea that there is anything more than one computer and one user. Or, if there is more than one, it must be an identical computer using its own local storage for its own copies of software, spreadsheets, documents, etc.

We had this problem nicely solved about 30 years ago. Professionals who understood data management and systems design used that knowledge to, uhmm, manage data and design systems. And they put it all together on hardware and operating systems that were designed from the ground up for multiple users and graceful resource sharing. You could think of this package of hardware and software as a computer specifically intended for business, or, more succinctly, a Business Computer (BC).

Then along came the Personal Computer (PC) and technology was dealt a blow from which it has yet to fully recover. Ignoring the clear implication that a Personal computer is designed for one person and not for a business, businesses flocked to gobble them up by the ton. People who taught themselves "how to program" using a toy were suddenly everywhere, producing software aligned with the Personal Computer focus. Who cares about file locking? Concurrency control? Hell, even file permissions and user IDs were superfluous and therefore omitted. Who needs the concept of a root user when there's only one user per computer? Let the user do anything they want! Basically all the solutions that were already well understood were thrown in the trash, only to be painfully, gradually, and only partially, rediscovered in the decades to follow.

Yeah, some wise ass will chime in to trash the multi-user computers of the 1970s as expensive, slow, and puny in their specs. Do you really think everything would have stagnated there? Just try to imagine where 30 years of progress in Business Computers could have taken us by now. The gap between that potential and today's reality -- where ignorant (or worse: arrogant) developers still assume everyone's computer is just like mine, and everyone runs as admin -- can be charged entirely to the damning influence of the Personal Computer and the software companies whose blatant lies were swallowed whole by an unsuspecting public.

Yeah, those with the experience to see through the lies learned to despise those marketing-driven empty-promise factories. But the public, with little computer knowledge, believed everything, and is only now gradually obtaining enough computer savvy to understand the need for things we had, and discarded, before half of us were even born.

frits:

While that is a more succint method, the one in the article is very similar to the "C" way of checking of a file exists. Except for the superfluous "on error" statement, that is.

BTW- Nice 2 second googling, but you should set oFile to Nothing before exiting your function.

Ha, Google? I asked an old VB6 buddy of mine who Googled it.

A little lazy with the proofreading today, eh?

his please were never granted

frits:

Buffled:

Fred, don't ever use "well designed" and "VB6" in the same paragraph again, unless you're include one of the following words:
wasn't
not
joke
fail

I have seen VB6 used to create a well-designed application. This is no joke - and wasn't a failure.

Was it called "Hello World!"?

Okay, you caught me. I've actually never seen a well-designed VB6 app. I was just being contrary and demonstrating that I could still say it while meeting your criteria...

Ike:

Err, uh, make that at least CHAR(12) to hold "FILENOTFOUND".

No...CHAR(9) is much better ;)

Where would TDWTF be without such things?

Function FileExists(FilePath As String) As Boolean

FileExists = Len(Dir(FilePath)) > 0

End Function