• (cs) in reply to welcor
    welcor:

    kipthegreat:
    WTFer:

    /I'm wearing the juice, man!


    That sounds kind of hot

    Read the pdf above (it's on page one as well, so you don't have to spend too long to find that quote).

    *shakes head in disbelief* 
    If it wasn't in a scientific paper, I'm not sure I'd believe it. Actually it's so implausible (& incomprehensible & unbelievable) I'm not sure I believe it even if it IS in a scientific paper.



    I did read it.  Well the first seven pages anyway.  I guess you're one of those who would place themselves in the 68th percentile on your ability to recognize humor (meaning, you're really in the <25th percentile).

    And I still think a dude covered in juice is pretty hot.

    That was more homoerotic humor there, in case you didn't catch it.
  • (cs) in reply to LJ

    Anonymous:
    KraGiE:
    omg.  I'd just quit.  No amount of money could keep me from looking at that and not exploding on the developer.  I don't care if I hurt their feelings or not. 


    I guess you never worked at an outfit with the 'statutory genius', someone who is big friends with the management, and considered to be a genius by the same, for some very mysterious reasons... you know the type, always comes up with 'novel ideas', 'new design patterns' or some new brilliant tool or technology, makes a quick demo, grabs the credits, and leaves a multitude of bugs and hair-brained 'design decisions' for the real coders, who are faced with the challenge of getting his trashware to work in real-world scenarios. Those debuggers obviously 'don't get it', and so he maintains his status, creating even more sh*t to prove his point.

    I've seen this scenario several times, even saw such a dolt creating his own database and binary network protocol, since standard databases were not optimal enough, and the network protocol was more efficient since it used all the bits and bytes in the stream to cram data in. That company went bankrupt, BTW, leaving my employer with a significant unpaid bill...

    Oh I have.  And I've quit.  No way am I going to let a guy like that become my manager.  No way in hell.  It's usually people like these that go out of their way to look good when in fact, they're dumber than dirt.  I worked with a guy like that who would talk, and talk, and talk with upper managers.  When time came to show and tell, he'd blame the rest of the developers for not making it happen.  Screw those people.

  • (cs) in reply to masklinn

    masklinn:
    Quite obviously one.

    most probably one row for each order item.

  • (cs) in reply to aikimark

    <font size="2" style="font-family: verdana;">

    aikimark:
    </font>

    <font size="2">most probably one row for each order item.</font>

    <font size="2" style="font-family: verdana;">


    Of course... if you're using tables to represent what should be rows, you might as well use rows to represent what should be columns.  Brillant!


    </font>

  • ByteJuggler (unregistered) in reply to Mike R
    Mike R:
    Why is it that the most arrogant software developers appear to be the dumbest?


    Because that's the only way they can maintain their belief that they actually know what they're doing.  It'd called being in "De Nile"
  • tim (unregistered)

    80GB?

    How the hell were they backing it up every day in a backup cycle - you know, like you're supposed to.

  • (cs) in reply to welcor

    One problem I have with that study is that the participants were recruited from college students, with the promise of extra credit in a class.  So, who needs extra credit?  Those that think they could benefit from it: the middle of the distribution.

    The students at the bottom of the class (and knew it) wouldn't enter, because they know they'd fail regardless.
    The students at the top (and knew it) have no need of extra credit.

    So, they excluded these groups from their analysis, and it may have changed the results strikingly.  I'd like to see these studies carried out again with a true random sample from the students, not just those enticed by extra credit.

    As for the quote... I believe it.  It certainly requires more testing... maybe that guy just had a bad batch of juice?

  • Max (unregistered) in reply to ammoQ
    ammoQ:
    Must be a fake. Nobody can be so stupid to build such a system.


    Seen this style before - think it was on here a year an a bit ago.  Maybe here is were Jay got his ideas from?
  • (cs)

    Imagine a commerce system.

    Imagine that it doesn't use a database.

    Imagine that it writes each order to a seperate file.

    Imagine that it does this to the same directory.

    Imagine an ext2 filesystem in Linux trying to cope with 100,000+ files in a single directory...


    I've seen this before, and I shudder to think that its happened elsewhere.

  • (cs) in reply to MikeB
    MikeB:

    This is the second time I've heard of someone doing this. Two times. That's a trend. It must mean something.

    BTW, I'm pretty good with a bow staff.



    so does this mean that with ALL those tables, he STILL cant get, like, 3 feet of air??
  • (cs) in reply to kipthegreat
    kipthegreat:
    welcor:

    kipthegreat:
    WTFer:

    /I'm wearing the juice, man!


    That sounds kind of hot

    Read the pdf above (it's on page one as well, so you don't have to spend too long to find that quote).

    *shakes head in disbelief* 
    If it wasn't in a scientific paper, I'm not sure I'd believe it. Actually it's so implausible (& incomprehensible & unbelievable) I'm not sure I believe it even if it IS in a scientific paper.



    I did read it.  Well the first seven pages anyway.  I guess you're one of those who would place themselves in the 68th percentile on your ability to recognize humor (meaning, you're really in the <25th percentile).

    And I still think a dude covered in juice is pretty hot.

    That was more homoerotic humor there, in case you didn't catch it.

    Thanks for the clarification. Apparently my humour recognition falls about in line with my expectations (==low). For what it's worth, I've never been fond of homoerotic jokes.

    Have nice day with your boyfriend.

  • (cs) in reply to welcor
    welcor:
    For what it's worth, I've never been fond of homoerotic jokes.

    Have nice day with your boyfriend.

    People who make so-called 'homoerotic jokes' are generally homophobes, not homosexuals.

    And I post, knowing even as I do that Safari will mangle the quoting. Ah well...

  • Rob (unregistered) in reply to Mike R
    Mike R:
    Why is it that the most arrogant software developers appear to be the dumbest?


    Consider the saying (and I paraphrase): "With true knowledge comes the understanding of how much you really DON'T know."
  • Chris (unregistered) in reply to ammoQ

    "Nobody can be that stupid"

    Oh yes they can. I interviewed with a company for a development DBA position that had a similar mess on their hands. I turned the offer down in part because I thought I would go insane dealing with that system before I was able to get rid of it.

  • (cs) in reply to RevMike
    RevMike:
    I can't beleive he used Hungarian notation like that!  'tbl' in front of everything!  Some people are just crazy.

    :)


    Ironically, one of the largest and most complex systems I've built so far uses the TBL_ prefix for every table. But this wasn't my idea, I had to copy that from the previous system. Needless to say that this is completely senseless (never used that notion for any other project) but at least it doesn't hurt much (compared to the countless other WTFs created by the originator of this naming scheme), except having to type tbl_ about 10000 times.

    On the other hand, it makes some sense (IMHO) to prefix views and indexes with "VW_" resp. "IDX_".
  • (cs) in reply to kipthegreat
    kipthegreat:

    I can understand that incompetent people can be incompetent at recognizing their own incompetence, leading to arrogance.  What I don't understand is how these people can often manage to convince so many other people that they are a "star". As I type this, a very prominent political leader comes to mind for some reason..



    Many managers (especially in small or medium companies) love the idea that the stars are making something special instead of following the usual practices like everybody else. The stars first "prove" that the usual way is inefficient (because they do it horribly wrong) and then they present their much better way of doing things.

    On the other hand, some things grow for several years; today it would be rather stupid to build your own web application framework (given the abundance of frameworks from MS, Sun, Apache etc.) but back in 1998, things looked different. So what if a system has been built in 1998 and is still in use today? At first glance, it's a WTF... lots of cheaply implemented re-invented wheels. But the standard wheels were not invented then, and the things that were standard then are mostly dead now (e.g. the Netscape web server and its proprietary APIs)
  • Pseudonym (unregistered)

    Of course, the real WTF is that he's using Hungarian notation by starting all the names with 'tbl'.

  • (cs)

    Obviously never got told what the R means in RDMS

  • (cs) in reply to Pseudonym

    Anonymous:
    Of course, the real WTF is that he's using Hungarian notation by starting all the names with 'tbl'.

    youre talking about "Systems Hungarian", right?

  • LarsW (unregistered) in reply to LJ

    I guess you never worked at an outfit with the 'statutory genius', someone who is big friends with the management, and considered
    to be a genius by the same, for some very mysterious reasons... you know the type, always comes up with 'novel ideas', 'new
    design patterns' or some new brilliant tool or technology, makes a quick demo, grabs the credits, and leaves a multitude of bugs
    and hair-brained 'design decisions' for the real coders, who are faced with the challenge of getting his trashware to work in
    real-world scenarios. Those debuggers obviously 'don't get it', and so he maintains his status, creating even more sh*t to prove his
    point.

    Amen. Happened to me twice. First huge PHP file upload/download and repository management system, and then a J2EE "universal translation and teaching tool". The last one  especially had a lot of stuff worthy of submissions to WTF, but I don't have the code anymore and I don't want to risk getting sued.


    Them: "Why is it taking you so long to fix the system? Our users are really upset. X designed it in weeks, and it is taking you months just to fix a few bugs."
    Me: "Because this is uncommented unmaintanable crap. I change things in one place and stuff explodes in three others."
    Them (sceptical): "But it worked fine when X worked here, it was only after he quit and you started that the system started to fail."
    Me: "Yes, but then you only tested it with one or two users at a time, and now we have hundreds, and this stuff wasn't designed with concurrency in mind. I basically have to rewrite everything from scratch."
    Them: "How long will that take you? A week? Two?"
    Me: "Gaaah!"

    Well, I can mention the DB design of the last project. For some reason they wanted each string only once in the database, probably to keep the size down. So words with different meaning in different languages, or different grammar could only occur once. For example the word"last"
     Swedish - cargo
     Swedish - sin
     English - final position
     English - staying power
    So the challenge was to represent language trees in a relational database, so that translations could be done. The obscenely well paid consultant had created a single Oracle table with a few attributes had all languages, all grammatical structures and all words... in the world. It is one of the established methods to represent a tree in a relational database, but books that discuss it say that performance is rarely good and it shouldn't be used for large data. Only for the demo, a Swedish-English translator and quiz tool using the database, the table had over 200 000 entries. First you had to look up the pkey for Swedish, and see that there were 150 grammatical structures associated with it (noun, verb, adjective, adverb...), then you looked up which sub-structures were associated with that structure (verb -> regular/irregular, monotransitive/bitransitive/complex-transitive...) and THEN... etc etc. Using this you were supposed to be able to create an infinite number of language quizzes. Imagine the time it would take to do the recursive queries once a few more languages were added.... It had a few more tables of course, for instance one that kept track which words in different languages were equivalent.

    To make the demo work, the people who tried to maintain it had ditched this and used whole sentences in the database with a random selection between them, and then a few random nouns.

    They had recieved millions of venture capital to design this. (This was during the dot com boom). Once this money drained out, they had managed to convince local authorities in Sweden to finance further development for a few years. Tax money down the drain of course...


  • (cs) in reply to Curtis

    how many rows in each table??

    Rows? What rows? Since they have a table for every order, they can super-opteymice the application and save disk space and encode the data to the column names.

  • (cs) in reply to ammoQ
    ammoQ:
    RevMike:
    I can't beleive he used Hungarian notation like that!  'tbl' in front of everything!  Some people are just crazy.

    :)


    Ironically, one of the largest and most complex systems I've built so far uses the TBL_ prefix for every table. But this wasn't my idea, I had to copy that from the previous system. Needless to say that this is completely senseless (never used that notion for any other project) but at least it doesn't hurt much (compared to the countless other WTFs created by the originator of this naming scheme), except having to type tbl_ about 10000 times.

    On the other hand, it makes some sense (IMHO) to prefix views and indexes with "VW_" resp. "IDX_".


    Where I work, we prefix views with V_. That makes sense, because view names and table names are wholly interchangeable in normal queries. But, um, we don't prefix tables with T_. Views are special, tables are not.
  • (cs) in reply to tim
    80GB?

    How the hell were they backing it up every day in a backup cycle - you know, like you're supposed to.

    Well that's obvious - you only need to back up the tables that were added sincethe last backup!
    :P

  • (cs)

    anyone in this day and age who is arrogant enough to re-invent the wheel ought to be publicly denounced.

  • (cs) in reply to b1xml2
    b1xml2:
    anyone in this day and age who is arrogant enough to re-invent the wheel ought to be publicly denounced.


    It happens all the time... it keeps us programmers busy. And I'm sure it also happens outside IT.
  • (cs) in reply to Grimoire

    Grimoire:
    Anonymous:

    I guess you never worked at an outfit with the 'statutory genius', someone who is big friends with the management, and considered to be a genius by the same, for some very mysterious reasons... you know the type, always comes up with 'novel ideas', 'new design patterns' or some new brilliant tool or technology, makes a quick demo, grabs the credits, and leaves a multitude of bugs and hair-brained 'design decisions' for the real coders, who are faced with the challenge of getting his trashware to work in real-world scenarios. Those debuggers obviously 'don't get it', and so he maintains his status, creating even more sh*t to prove his point.

    I've also worked for a company like that.  We "merged" with another company, and their chief designer/developer/coder/CTO was exactly like this.  He wrote his own database, which had its own bastardized version of SQL, as well as his own XML parser.  Everyone for his side of the company considered him the god of developers.

    Everything "worked", as long as you didn't ask it to do anything other than what it was originally designed and implemented to do.  Want to parse an XML file with a single, large node?  Be prepared to wait an hour or so.  Want to speed of the DB by removing old data?  Nope, the DB actually slows down the more you delete items from it.  Never shrinks either.  You can delete every record in the DB, but it will still be the same size as before.

    And you couldn't pull out ANYTHING, since each component was tightly integrated with the rest of the system.  The DB, business logic, XML parser, everything, was all mixed together in the different "classes".  And I use the term "classes" lightly, as the classes were essentially just dumping grounds for a bunch of functions, rather than a designed OO architecture.

    Fortunately, he left about 6 months after the merger.  Unfortunately, his code didn't.  There was a push to re-write the client from the ground up, but why make that kind of expediture when you can sell the crap we currently have to customers?  Never mind the fact that it costed us more money to maintain a customer than the customer actually paid, but what the hell, any sale is a good sale, right?

    The phrase "f'ing Gary" become the unofficial company slogan...

    OMG, I think that I used to work with f'ing Gary

  • (cs) in reply to the_saint

    BTW: my first post

  • Anonymous (unregistered) in reply to Ytram

    Ytram:
    :
    Anyway after tbl comes tbm


    Well crap, I wonder what happened to aaa through tbk?

    aaa through tbk have been used.  The space doesn't get freed up again.

  • me (unregistered)
    Alex Papadimoulis:

    On the order-entry system, the slowdown was a result of Microsoft SQL Server improperly indexing table pages. Jay's design was brilliant: each order had its own table. This way, any new changes to the table template won't affect the old orders.

     

    This nonsense is very common. I have had to clean up several databases that had sets of tables (new set for each customer). A common reason given to me if I ask why this design was chosen was security. It is far too mind boggling to consider the rammifications of having all the data in one table (or set of tables).

    A variation on this is to use different tables for different time periods. Extra points for being used in conjunction with the above.

    There is nothing "happier" than debugging code in which table names are being dynamically assembled to deal with this type of mess. "SELECT * FROM "+custID+"_"+year_value+"_orders;"

    :(

  • (cs) in reply to JoeyLemur
    JoeyLemur:
    Imagine a commerce system.

    Imagine that it doesn't use a database.

    Imagine that it writes each order to a seperate file.

    Imagine that it does this to the same directory.

    Imagine an ext2 filesystem in Linux trying to cope with 100,000+ files in a single directory...


    I've seen this before, and I shudder to think that its happened elsewhere.



    Now see a COMPETENT programmer would have made a new directory for every day or week and thus prolonged the final reckoning by months or years. Of course...there are advantages to creating a directory for each reservation...

  • fffffffffff (unregistered) in reply to Jiminy Cricket

    Wow, that is completely insane. A WTF in the truest sense.

  • (cs)

    Maybe it's possible he didn't know of the Identity property of an int-type column?
    My company queries on that and a part ID for large inventory-type tables.

  • (cs) in reply to Zair
    Zair:
    One problem I have with that study is that the participants were recruited from college students, with the promise of extra credit in a class.  So, who needs extra credit?  Those that think they could benefit from it: the middle of the distribution.

    The students at the bottom of the class (and knew it) wouldn't enter, because they know they'd fail regardless.
    The students at the top (and knew it) have no need of extra credit.

    So, they excluded these groups from their analysis, and it may have changed the results strikingly.  I'd like to see these studies carried out again with a true random sample from the students, not just those enticed by extra credit.

    As for the quote... I believe it.  It certainly requires more testing... maybe that guy just had a bad batch of juice?


    I noticed the same thing.  Even a random sample of students from a university wouldn't really be very random.  On average, students who are in a university will perform better on standardized tests than non-university students.  So the fact that most students rated themselves in the 60-70% range might be an accurate assessment of their competence compared to the general public.  But overall I think the point the study was making is very plausible.
  • (cs) in reply to kipthegreat
    kipthegreat:

    I noticed the same thing.  Even a random sample of students from a university wouldn't really be very random.  On average, students who are in a university will perform better on standardized tests than non-university students.  So the fact that most students rated themselves in the 60-70% range might be an accurate assessment of their competence compared to the general public.  But overall I think the point the study was making is very plausible.


    :-/  I read from the study: Generally most people think they are slightly-above-average, almost independend of how well they actually perform. In other words: People are generally bad at judging themself; slightly above average people are right only by chance.
  • (cs) in reply to JoeyLemur
    JoeyLemur:
    Imagine a commerce system.

    Imagine that it doesn't use a database.

    Imagine that it writes each order to a seperate file.

    Imagine that it does this to the same directory.

    Imagine an ext2 filesystem in Linux trying to cope with 100,000+ files in a single directory...


    I've seen this before, and I shudder to think that its happened elsewhere.



    It has, I can say.  A company I worked for a few years ago had such a system, matching almost exactly that.  And ext2 was NOT designed for that many files in a single directory. 

    The orders were in some binary format that only the client application could read, no one had the source to make a "minor maintaince change".  When the system started acting slow, it had to be the fault of the systems administrators who simply didn't know how to keep the system going.  Middle management refused to believe that their application (that they had paid for support from the vendor on for at least 3 years, at 200k/year) was a steaming pile.  We went through two hardware upgrades that solved the problem for 2-3 months, each.  The vendor, of course, was out of business.
    Finally, we tried changed the filesystem over to ReiserFS, knowing (at the time) it was unstable.  Searching still took some time, but management saw the system working again, patted themselves on the shoulders, and fired half of our incompetent team for taking so long to fix the problem.
  • SteveSenior (unregistered)

    Dear Steve,

    Quit. We have better jobs for better programmers. If you follow Jay around and fix his messes you only make him look good. Either quit cleaning up after Jay or quit the company.

    --Steve

  • Wang (unregistered) in reply to wakeskate

    wakeskate:

    surely it could only be dynamically generated and a union would be ridiculous - can never tell if there is sarcasm...  besides in some db's # of tables in a query is limited (sql server, for example, a mere 256)


    it would go on until sql server couldn't make any more tabes, i'm guessing that orders < 9999 wouldn't have leading zeros.

    this "database of databases" wtf is always funny!

    Erm, sorry I can't tell if this is sarcasm or not.  Sql Server 2k (you know, the one that becomes obsolete this year) is limited to the max number of objects per database, in turn limited by the number of objects in an instance.  This is either 2,147,483,647 or limited by memory.

    Perhaps you are thinking of  decade old technology..?

     

  • (cs) in reply to Wang
    Anonymous:

    wakeskate:

    surely it could only be dynamically generated and a union would be ridiculous - can never tell if there is sarcasm...  besides in some db's # of tables in a query is limited (sql server, for example, a mere 256)


    it would go on until sql server couldn't make any more tabes, i'm guessing that orders < 9999 wouldn't have leading zeros.

    this "database of databases" wtf is always funny!

    Erm, sorry I can't tell if this is sarcasm or not.  Sql Server 2k (you know, the one that becomes obsolete this year) is limited to the max number of objects per database, in turn limited by the number of objects in an instance.  This is either 2,147,483,647 or limited by memory.

    Perhaps you are thinking of  decade old technology..?

     



    I don't want to imagine a system where a 256-tables-per-query limit becomes relevant.
  • Janos (unregistered) in reply to ammoQ

    oh no, I have seen such a man with my own eyes. he created his own database mgmt system which stored each record in a separate file. thus to store 1 byte took at leat 4096. Once he started to teach me on how to spare storage room by carefully choosing between various primitive types (long, int). I had that internal smile as he was talking :)

  • (cs) in reply to dhromed

    dhromed:
    ammoQ:
    On the other hand, it makes some sense (IMHO) to prefix views and indexes with "VW_" resp. "IDX_".


    Where I work, we prefix views with V_. That makes sense, because view names and table names are wholly interchangeable in normal queries. But, um, we don't prefix tables with T_. Views are special, tables are not.

    It makes as much sense to prefix views as it does to prefix Private classes and Public classes with access indicators (pubSomeClass , pvtMyClass). Remember that a view is a virtual table, just named in a confusing way. Views function exactly like a regular table (provided the triggers are in place). Such information distinguishing the two should *not* be exposed to the user (application programmer). It's a fundamental of of simplification and information-hiding.

  • (cs) in reply to LJ

    Anonymous:
    KraGiE:
    omg.  I'd just quit.  No amount of money could keep me from looking at that and not exploding on the developer.  I don't care if I hurt their feelings or not. 


    I've seen this scenario several times, even saw such a dolt creating his own database and binary network protocol, since standard databases were not optimal enough, and the network protocol was more efficient since it used all the bits and bytes in the stream to cram data in. That company went bankrupt, BTW, leaving my employer with a significant unpaid bill...

    Mem'ries... light the corners of our mind!

    This reminds me of my first job when my boss would decide to change primary keys on tables - and not tell anyone - for his Oh-my-god-the-client-is-flipping-out-we-have-to-fix-this-even-if-it-means-breaking-everything-else projects.  This was the same guy who brought an air mattress to work, slept at work "when he could", and worked "100+ hours a week" to work his magic.  At least, that's what he reminded everyone, lest they forget who was in charge.  To defy this man... no, no divine being!... was an act of heresy.  He got to this position because he built the first working web product.  I don't know how many times I was flamed for having an independent thought.  "You're just a punk programmer,"  I was told.  God forbid we built anything right the first time... we might have actually had time to improve our product rather than fix it.  By the time I left, simple queries were taking nearly a minute to complete. 

    I salute you, 12th percentile.

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

    dhromed:
    ammoQ:
    On the other hand, it makes some sense (IMHO) to prefix views and indexes with "VW_" resp. "IDX_".


    Where I work, we prefix views with V_. That makes sense, because view names and table names are wholly interchangeable in normal queries. But, um, we don't prefix tables with T_. Views are special, tables are not.

    It makes as much sense to prefix views as it does to prefix Private classes and Public classes with access indicators (pubSomeClass , pvtMyClass). Remember that a view is a virtual table, just named in a confusing way. Views function exactly like a regular table (provided the triggers are in place). Such information distinguishing the two should *not* be exposed to the user (application programmer). It's a fundamental of of simplification and information-hiding.



    I see your point, but if an application programmer uses a tool like TOAD or Tora (for Oracle), he must see the difference between a view and a table: There is a tab "Tables" for tables and "Views" for views. Having a name scheme with "vw_" prefix helps to find the right tab in the tool.
    In other environments, the database structure is hidden behind a mapping (Hibernate comes to my mind) and application programmers never sees tables or views.
  • (cs) in reply to Zair
    Zair:
    One problem I have with that study is that the participants were recruited from college students, with the promise of extra credit in a class.  So, who needs extra credit?  Those that think they could benefit from it: the middle of the distribution.

    The students at the bottom of the class (and knew it) wouldn't enter, because they know they'd fail regardless.
    The students at the top (and knew it) have no need of extra credit.

    So, they excluded these groups from their analysis, and it may have changed the results strikingly.  I'd like to see these studies carried out again with a true random sample from the students, not just those enticed by extra credit.


    Hmmm, I'm not so sure about that. Students at the top of the class are usually total keeners and will go for the extra marks even though they don't need them. Students at the bottom of the class would jump at a chace for free marks especially when it doesn't involve having to actually study. Students in the middle would also benefit from the extra marks, so I believe the sample would probably be pretty even.

    I confess I only read the first two pages of the article, is any information given about the average grades of the sample given?
  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    dhromed:
    ammoQ:
    On the other hand, it makes some sense (IMHO) to prefix views and indexes with "VW_" resp. "IDX_".


    Where I work, we prefix views with V_. That makes sense, because view names and table names are wholly interchangeable in normal queries. But, um, we don't prefix tables with T_. Views are special, tables are not.

    It makes as much sense to prefix views as it does to prefix Private classes and Public classes with access indicators (pubSomeClass , pvtMyClass). Remember that a view is a virtual table, just named in a confusing way. Views function exactly like a regular table (provided the triggers are in place). Such information distinguishing the two should *not* be exposed to the user (application programmer). It's a fundamental of of simplification and information-hiding.



    But a view is not an eqivalent to a table.  Views are frequently not updateable.  This is key information that must be exposed to a developer.  Second, depending on your platform, performing a join between a view and a table can be radically less efficient than performing a join between two tables.
  • (cs) in reply to RevMike

    I think I can see what happened here. This guy couldn't work out how to store multiple items in a single order. He conceptualized each order as its own table of items and couldn't break away from that.

    That he forged on and implemented this "design" is very arrogant. I can see myself having that "multiple items per order" conceptualization problem (more than) a few years ago, but I KNOW I would have thought, "No way man. There's got to be a better way."

  • still working there (unregistered) in reply to cconroy

    Sorry, where I work the lead moron did just that. all of the data is in what is basically a 2 column table. Actually, it is 6 columns, I think, because you have a column for String, Int, Long, date, object, etc. In order to get one patient record with 150 fields, you have to do 150 selects. The query, when you print it out, is literally 10 pages long. To get one record! Oh, I forgot, you have to join with another table to find out the data type for each and every item so that you know what column you will find it in. So, you have to do a 3 column join to get each field, and you have to do this 150 times to get one patient record. But don't worry, we speed it up by running 3 explains on every query at runtime and selecting the best. A customer called to complain that they were trying to purge a lousy 40,000 patients from a db with 80K patients in it. Do the math. It comes out to like 12 MILLION deletes to delete 40K records. They killed the purge after 25 hours. Oh, one last detail to the nightmare: this crap is in the 'core' code that is used by all the applications the company builds. (The new team replaced this nightmare with a standard relational data model and the sun came out again...)

  • (cs)

    He's taking very seriously the integrity of the database!

    One to Many !


    Alex Papadimoulis:

    After spending a few days of combining the ungodly amount of order tables, Steve was able to increase performance by a few magnitudes and reduce the database size from 80GB to 2GB. Jay, still the star-developer, scoffed at the "hack" and said he will be evaluating different database systems for future projects.

  • (cs) in reply to still working there
    Anonymous:
    Sorry, where I work the lead moron did just that. all of the data is in what is basically a 2 column table. Actually, it is 6 columns, I think, because you have a column for String, Int, Long, date, object, etc. In order to get one patient record with 150 fields, you have to do 150 selects. The query, when you print it out, is literally 10 pages long. To get one record! Oh, I forgot, you have to join with another table to find out the data type for each and every item so that you know what column you will find it in. So, you have to do a 3 column join to get each field, and you have to do this 150 times to get one patient record. But don't worry, we speed it up by running 3 explains on every query at runtime and selecting the best. A customer called to complain that they were trying to purge a lousy 40,000 patients from a db with 80K patients in it. Do the math. It comes out to like 12 MILLION deletes to delete 40K records. They killed the purge after 25 hours. Oh, one last detail to the nightmare: this crap is in the 'core' code that is used by all the applications the company builds. (The new team replaced this nightmare with a standard relational data model and the sun came out again...)


    Let me guess: This was done on an Oracle database, right?
    A database built upon a database... I've had this crazy idea before, but I would never have imagined someone would really do that in real world!
  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    JoeyLemur:
    Imagine a commerce system.

    Imagine that it doesn't use a database.

    Imagine that it writes each order to a seperate file.

    Imagine that it does this to the same directory.

    Imagine an ext2 filesystem in Linux trying to cope with 100,000+ files in a single directory...


    I've seen this before, and I shudder to think that its happened elsewhere.



    Now see a COMPETENT programmer would have made a new directory for every day or week and thus prolonged the final reckoning by months or years. Of course...there are advantages to creating a directory for each reservation...

    We hacked that in some years ago. Right about the time that management said 'hey, we should be backing this stuff up, and maybe even have a failover system for it', and rsync would just grind to a halt...

    It was also about this time that I realise 'System Administrator' is shorthand for 'Local Deity That Pulls Solutions Out Of His Ass'.

  • Zebby (unregistered)

     

    I've heard of this before... there must be some database design philosophy somewhere that says to do this! Either that or some old school database that makes you be this stupid.

     

Leave a comment on “Hacking the jProject”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article