• (unregistered)

    I imagine that, if I knew I were leaving a company, and I hated that company, I might design a piece of software that totally disregarded accepted standards of security and database normalization...a horribly gimped-up piece of software that would stand as a testament to my hatred for years to come, long after I had moved on to greener pastures...a piece of software so horribly malevolent that it would make maintenance programmers who came after me hate the company as well.[8o|]

  • (cs) in reply to

    <FONT style="BACKGROUND-COLOR: #efefef">There's an old saying about burning your bridges. But, in this case, I know that Programmer X is still a developer there ... and developers other ... umm ... wonders like this.</FONT>

  • (unregistered)

    Hopefully Jakeypoo, in the intervening time from when this was first post to now, has matured as a programmer and now understands the brilliance of this code. You see the learned developer who created this calendar has a deep understanding of DB performance tuning (if this SQL Server 2000). By de-normalizing this data it allows for better cache performance with a minimum of disk IO. A read for a given data, if it’s not already in the cache, will hit the disk and load the page _and the following pages_ into memory. Thus the user has now inadvertently loaded his whole week and any lookups to following days is served out of DB cache! Brilliant!  

  • (unregistered)

    I'd have to say someone doesn't understand the concept of relational databases... using a comma seperated string in ANY field is just plain stupid.

    Can you imagine having to query the database for all of the meetings for say... the web department?

    select * from table where strIDWho like '%-3%'

    Gee...

  • (unregistered)
    Alex Papadimoulis:

    According to the hit counters, 2/3 of the regular visitors to the site are still on vacation. So for us unfortunate few stuck at work, here is one of my favorite, yet least-viewed posts from a while back.

    I hereby issue a challenge for you to justify the actions of Programmer X, as described by Jakeypoo:

    I'll be the first one to admit that I'm relatively new to programming.  "I'm relatively new to programming."  There.  So far be it from me to criticize what could well be a masterfully architected piece of software, so I won't color this.  I'll just present the facts and let you, the reader, decide if a programmer at my company is stupid.

    I was recently asked by the company to add some functionality to the employee calendar that Programmer X made.  Specifically, they requested that the entries be downloadable as vcs files, so that they could be imported into Outlook for PC users, iCal for Mac users, and whatever Linux folks use to schedule their client meeti-- ... wait, no ... dates ... err ... parti -- ... umm ... social even-- ... aha,  television shows.

    Anyhoo, wading through this programmer's source code and table structures got a little odd.  Here's a screenshot of the layout of tblCalendar.

    [image]

    If I had to pick my two favorites, they'd have to be datDate (just in case you don't know what datatype a variable called "Date" would be) and strIDWho.  Even though the column name clearly describes what's in it, I'll entertain the vague possibility that some of you may not know what strIDWho contains.  Why, it's a comma separated list of the IDs of staff members from tblStaff.  Unless it involves the whole staff, in which there's a 0.  Or if it involves someone outside the staff, it's a -1, a comma, and then a list of the names involved. Or a -2 for the entire programming department. Or a -3 for the entire web department. So a typical value in this column is "-2, 2, 4, 5, -1, Jim and Jane Douchebag." 

    The calendar itself is rendered entirely client side.  The justification for this?  The server isn't that much faster than our individual computers, so why should the server do all the work? And naturally, when a calendar entry is saved, a SQL command string is built client side (in Javascript) and sent to the server to update the database.

    Jakeypoo also metions that the application wasn't one of those build & patch cases -- this was the architecture as concieved on day one.

  • (unregistered)

    The real WTF is the attack on Linux users in the introduction. Guess which operating system the genius who wrote this was using?  I'm sure the "clients" in your client meeting are impressed.  And the women you take on "dates".

  • (cs) in reply to
    :
    The real WTF is the attack on Linux users in the introduction. Guess which operating system the genius who wrote this was using?  I'm sure the "clients" in your client meeting are impressed.  And the women you take on "dates".


    Yeah really, us linux users use mythTV or Freevo to keep track of television.  Too bad he was right about the whole no dates and social events.
  • (unregistered) in reply to

    Ease up - I hardly think that statement qualifies as an 'attack'.  And as a Linux user myself - I still thought it was kind of funny.  If you came to any of our users groups meetings I think you'd agree too

  • (unregistered)

    fired....

  • (unregistered)

    Filling strIDWho with a comma separated list is really a WTF, how oldfashioned.

    He should have filled strIDWho with XML, than he would have been a cuttingedge programmer with a great architectural vision.

  • (cs) in reply to

    I'd have to say someone doesn't understand the concept of relational databases... using a comma seperated string in ANY field is just plain stupid.


    Agh. I agree.with that. Completely.

  • (cs)

    CSV - Completely Sightless Vision

  • (unregistered)

    What's the problem with datDate? ProgrammerX clearly has well established naming conventions, the prefix 'dat' meaning date; why should he break it for this one instance?

  • (unregistered) in reply to
    :
    What's the problem with datDate? ProgrammerX clearly has well established naming conventions, the prefix 'dat' meaning date; why should he break it for this one instance?

    I agree that leaving the "dat" on "datDate" is a good idea for convention, but the date must have served some purpose and probably should have had that purpose embedded in its name.

  • (unregistered) in reply to
    :
    I'd have to say someone doesn't understand the concept of relational databases... using a comma seperated string in ANY field is just plain stupid.

    Can you imagine having to query the database for all of the meetings for say... the web department?

    select * from table where `strIDWho` like '%-3%'

    Gee...

    For those of us still using SQL 7 without good 'ol table variables, passing arround poor man's arrays (i.e. comma-delimited lists in a varchar), thas type code has its use. Of course you forgot your delimiter but whatever.

    Aside from all of our gut instincts and training telling us this is just wrong, is there proof that it's actually code or performance inefficient?

    What would the equivalent code be in a relational DB be...

    SELECT * FROM Table WHERE EXISTS (SELECT * FROM WhoTable WHERE TableID = TableID)

    That's more to type. Would it be faster? Wouldn't that depend on the server hardware and the relative size of the tables? What if they were billion-row tables? Would it be faster to join to another multi-billion row table or do a LIKE on a small indexed text field?

  • (cs) in reply to

    <FONT size=2>Aside from all of our gut instincts and training telling us this is just wrong, is there proof that it's actually code or performance inefficient
    </FONT>

    Please, please tell me your post was a joke [:O]! Such a CSV field cannot be indexed (well, in a useful way, that is). A relational solution will be faster and more efficient every single time, no matter the number of rows, assuming the EventID and EmpID are indexed.

    Easier to type? Seriously? Just think of how much more work it is to convert the field to an array, then query the table for each item ...

  • (cs)

    Alex -- we should have year-end "Comments WTF" awards.  I think we may have a winner. 

    Actually, I think this table is ingenious.  Don't you see? It is the ultimate Table!  It can store all data in the universe !  Everything, every event, every attribute of every person, can ultimately be broken down into Who, What, Where and a date !!!  (I bet there's even a How column in there somewhere as well!)

    To be able to view the contents of this table would answer all of the questions in the universe! (or at least since 1/1/1900 !)

  • (unregistered)

    Using hungarian notation in a database drives me insane. 

    intSomethingID .... I think the ID gives away its probably an INT

    samething for date.

    Another thing I hate is intTablenameFieldName naming.

    One - What if you had to change your tablename, you then need to alter all of your columns and then all of your code.

    Two - same goes for hungarian column names.  What if  intBudget all of a sudden has to handle decimals, you need to rename and rename all of your code.

     

    Stop the Madness!

  • (cs) in reply to

    My personal pet peeve is the practice of using capitalization when forming table/column names that contain multiple words.  Most (if not all) SQL DBs are case insensitive for table/column names and several drivers/interfaces I've worked with always lowercase everything, which makes them much harder to read.

    something_id is only one character longer than SomethingID (or SomethingId) and to me is much easier to read.  Especially when the casing gets lost, and the word count increases ( ie someintermediatelinkingtableid )



  • (unregistered) in reply to

    Well, if the DB is SQL Server, you cannot have a field called "Date", or mysterious and difficult to trace errors occur later on when performing SQL statements.

  • (unregistered) in reply to

    Funny how almost every entry on this site uses Hungarian notation in some form or another.

  • (cs) in reply to
    :
    Well, if the DB is SQL Server, you cannot have a field called "Date", or mysterious and difficult to trace errors occur later on when performing SQL statements.


    With the version of SQL Server I am using at work, we have several column names that are SQL keywords.  There's never a problem so long as column names are bracketed.  The following runs just fine for me in SQL Query Analyzer

    CREATE TABLE [wtf] (
        [select] [int] NULL ,
        [from] [int] NULL ,
        [where] [int] NULL ,
        [order by] [int] NULL
    ) ON [PRIMARY]
    GO

    SELECT
        [select],
        [from],
        [where]
    FROM
        wtf
    WHERE [order by]=2
    GO

    You could write some really interesting SQL code by [mis]using this "feature".

  • (unregistered) in reply to

    Usually people don't just use Date. 

    created_date, modified_date, etc.

     

    So another strike for dteDate!

  • (unregistered)

    datDate may be named that way because Date is a reserved word.  (That's a lame justification--in such a case I'd probably have used theDate instead:  I don't do Hungarian warts.)

  • (cs)

    Blue is officially my hero. Imagine integrating this with subqueries.

    SELECT [SELECT COL_1] AS [WHERE], [FROM DATES], [INNER JOIN], [CREATE TABLE] AS [WHERE X] FROM (SELECT [ORDER BY] FROM DAY.[WHERE], TABLES) INNER JOIN WHERES.[SELECT] WHERE [FROM DAY] = (SELECT * FROM INNERJOIN) AND [WHERE]

    I'm not certain of the validity of all that, but it's oh so fun.

    Oh, the comment that first came to mind when I saw this, related to an earlier one, is when this 'demo-hungarian' is used, and later the datatype has to change, but the programmer is too lazy to go back and change names, so you end up with a datDate that's a 64-bit int, intField that's a floatingpoint, and decCash that's a varchar.

  • (unregistered) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    <FONT size=2>Aside from all of our gut instincts and training telling us this is just wrong, is there proof that it's actually code or performance inefficient
    </FONT>

    Please, please tell me your post was a joke [:O]! Such a CSV field cannot be indexed (well, in a useful way, that is). A relational solution will be faster and more efficient every single time, no matter the number of rows, assuming the EventID and EmpID are indexed.

    Easier to type? Seriously? Just think of how much more work it is to convert the field to an array, then query the table for each item ...

    You don't have to convert the field to an array (or whatever construct approximates it in SQL) in most cases. The contorted LIKE will also allow a join to the text names which correspond to the IDs in the list. The code (and perhaps efficiency) gets longer if you frequently look for groups of IDs. Instead of being able to use an IN you end up with a lot of OR'd LIKEs. So in those cases it probably become performance poor.

    But I've seen MS SQL behave strangely enough when joining tables to not be convinced that in all environments having separate tables for this setup will be FASTER. Again, sure, it's more elegant and it's the "right" way to do it and it's definitely more flexible. But I haven't seen proof that it's faster.

  • (unregistered) in reply to
    :

    Using hungarian notation in a database drives me insane. 

    intSomethingID .... I think the ID gives away its probably an INT

    samething for date.

    Another thing I hate is intTablenameFieldName naming.

    One - What if you had to change your tablename, you then need to alter all of your columns and then all of your code.

    Two - same goes for hungarian column names.  What if  intBudget all of a sudden has to handle decimals, you need to rename and rename all of your code.

     

    Stop the Madness!

    We use both. :)

  • (cs)

    You know maybe it is just because I am a younger programmer, however I like adding "int", "bln" etc to the variable and column names it helps me keep things straight in terms of what data types I am using.

  • (cs) in reply to iowacbr600f4guy

    I've been away a while, so I've missed most of this. I have only one thing to add:

    @Jeff: One needn't bother with a relational database table to store the sum of all human (and non-human) knowledge; any data you require can be programmatically derived from the number 42. It may take a while, but trust me, it's in there somewhere.

  • (cs)

    >>But I've seen MS SQL behave strangely enough when joining tables to not be convinced that in all environments having separate tables for this setup will be FASTER. Again, sure, it's more elegant and it's the "right" way to do it and it's definitely more flexible. But I haven't seen proof that it's faster.

    Then you should look into how to create indexes,  and also techniques for writing efficient SQL. 

    It's not only faster, but if you have lots of data, it will be faster exponentially.  

  • (unregistered) in reply to

    Are you a complete idiot?  There is NO place for hungarian notation for database field names.

    JEEZUS!

  • (unregistered) in reply to iowacbr600f4guy

    iowacbr600f4guy:
    You know maybe it is just because I am a younger programmer, however I like adding "int", "bln" etc to the variable and column names it helps me keep things straight in terms of what data types I am using.

    Helps keep you straight!  Come on - as mentioned before, does the name anything_id confuse you?  For some reason do you think this is a varchar?  Is created_date some mystery datatype?

    If you doing this to "Keep Track" you should add the size to, that way when you have to pass into a stored proc you don't need to look it up.  vch255_Users_FirstName

    And once again, what happens when you have to change a datatype?  You need to change the name and then go and change all your SP's and code. 

    ROOKIE MOVE.

  • (unregistered)

    Hey, us Linux users aren't that bad :(

  • (unregistered) in reply to
    :
    What's the problem with datDate? ProgrammerX clearly has well established naming conventions, the prefix 'dat' meaning date; why should he break it for this one instance?


    The naming is not the WTF here but I ask myself for what this column is good for at all. The start- and end-time-columns are containing the date as well (not only the time) and when there are events lasting longer than one day, you will use these two columns instead anyway (or there is a column missing).


    Regards, Lothar
  • bytemaster (unregistered) in reply to

    [quote user=""][quote user="iowacbr600f4guy"] Come on - as mentioned before, does the name anything_id confuse you?  For some reason do you think this is a varchar?  Is created_date some mystery datatype?[/quote] Unfortunately, for more than one company, these were often char/varchar columns, for various resons - sometimes business related, but often stupidity.

    CAPTCHA: incassum -- incassum you don't get it right the first time, make it a string!

Leave a comment on “tblCalendar - Editor's Edition”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article