Database rats nest
-
I once came across an Access database (already WTF) that used columns instead of rows for a Calendar like application ! The Calendar table had (from memory) 1 row for each day with 50+ columns for each half hour block from 8:00am. Now you can imagine the horror it was to try to maintain such an application. The reports that ran of this dog were nightmarish, even to SELECT a single day that had 'something' happening on it looked something like SELECT * FROM Calendar WHERE Time800 <> '' OR Time830 <> '' OR Time900 <> '' .. OR Time1600 <> '' I can imagine what the coder would have said when asked to make the days start a little earlier than 8:00, "Oh, sure, that'll take at least another 4 months to re-schema the database and touch up all the affected queries". And when the original developers were sacked for taking way took long and we took over the project we were questioned why we were completely rewriting it from scratch. The above Calendar table was just one example in this diseased rats nest, there were plenty of others like using hidden form controls as global variables. You would open up the main form and had absolutely no hope of actually telling what it would look like when run since it was completely covered in these demons from hell. I just hate with a passion code that does not read simple, I hate it when I cannot confidently make a simple change to some code without it screwing up something completely unrelated because the variable I modded was global and had different meanings depending on where it was called from. Anyway that's my rant :) Code should be simple. No excuses.
-
I once came across an Access database (already WTF) that used columns instead of rows for a Calendar like application ! The Calendar table had (from memory) 1 row for each day with 50+ columns for each half hour block from 8:00am. Now you can imagine the horror it was to try to maintain such an application. The reports that ran of this dog were nightmarish, even to SELECT a single day that had 'something' happening on it looked something like SELECT * FROM Calendar WHERE Time800 <> '' OR Time830 <> '' OR Time900 <> '' .. OR Time1600 <> '' I can imagine what the coder would have said when asked to make the days start a little earlier than 8:00, "Oh, sure, that'll take at least another 4 months to re-schema the database and touch up all the affected queries". And when the original developers were sacked for taking way took long and we took over the project we were questioned why we were completely rewriting it from scratch. The above Calendar table was just one example in this diseased rats nest, there were plenty of others like using hidden form controls as global variables. You would open up the main form and had absolutely no hope of actually telling what it would look like when run since it was completely covered in these demons from hell. I just hate with a passion code that does not read simple, I hate it when I cannot confidently make a simple change to some code without it screwing up something completely unrelated because the variable I modded was global and had different meanings depending on where it was called from. Anyway that's my rant :) Code should be simple. No excuses.
Steve Fillingham wrote:
1 row for each day with 50+ columns for each half hour block from 8:00am
More than 50 half hours after 8am? Which planet was that calendar designed for - mercury or venus?!? ;)
-
Steve Fillingham wrote:
1 row for each day with 50+ columns for each half hour block from 8:00am
More than 50 half hours after 8am? Which planet was that calendar designed for - mercury or venus?!? ;)
-
Steve Fillingham wrote:
1 row for each day with 50+ columns for each half hour block from 8:00am
More than 50 half hours after 8am? Which planet was that calendar designed for - mercury or venus?!? ;)
Good pickup :) I dont know about the Calender but the dev was definitely not of this Earth :)