• codemonkey73 (unregistered) in reply to L.

    Because you can get SqlServer Express for free and better results + tools.

  • (cs) in reply to dignissim
    dignissim:
    Nagesh:
    Nagesh:
    Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.

    [image]

    That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.

    Is that what passes for Yoga in Indian? Man, you guys do everything half-assed.

    True yoga is about relaxation. not pulling muscle resulting in severe injury

  • Kyle H (unregistered)

    As a professional database developer whose father is a dentist using Eag....umm, Beaglesoft today, I can verify that they now actually practice some good SQL techniques like using WHERE clauses and not pulling every column.

    But it's still a really awful overall design - highly denormalized, identical data in different tables with different column names, no real parent-child relationships, and the crappiest "non-technical user" query GUI I've ever seen.

    Oh, and it's all in Sybase. Yay!

    Entrepreneurial types: The dentistry world is crying out for a decent modern OO-based practice management system, and they have way more money than they know what to do with it.

  • Brian White (unregistered) in reply to Weeks before D-Day
    Weeks before D-Day:
    I hope this is sarcasm....

    In case it isn't, besides the horror of making views to correspond to the columns you need for every current query, your maintenance programmers will find you in your sleep and kill you if you ever need to add a column to a table.

    Don't worry. Only successful companies need to deal with adding columns to tables :P

  • Brian White (unregistered) in reply to Cbuttius
    Cbuttius:
    A WHERE clause is not enough, the table would also need to be indexed.

    ...

    The table would not need to be indexed to resolve the problem of pushing megabytes of data across the wire to the remote office.

  • someone that would know (unregistered) in reply to Kyle H

    WHERE clauses have always been used by the software in question and SELECT * was something you might see in code written 15 years ago.

    This "Classic WTF" post is grossly inaccurate and a hit job.

  • Remy Porter (unregistered)

    I'm sorry guys, but I've got some really bad news. Alex has unexpectedly passed, and Mark and I need to talk about the future of this site. Stay tuned for details. Sorry.

  • The Database Elf (unregistered)

    Try that with 40,000 doctors and you'll know why the NHS patient record integration project is $1 billion over budget and four years late.

  • (cs) in reply to Remy Porter
    Remy Porter:
    I'm sorry guys, but I've got some really bad news. Alex has unexpectedly passed, and Mark and I need to talk about the future of this site. Stay tuned for details. Sorry.

    This is getting old and also boring.

  • (cs) in reply to Nagesh
    Nagesh:
    True yoga is about relaxation. not pulling muscle resulting in severe injury
    You're doing it wrong! Pulling muscle should be relaxing.
  • (cs) in reply to frits
    frits:
    Nagesh:
    True yoga is about relaxation. not pulling muscle resulting in severe injury
    You're doing it wrong! Pulling muscle should be relaxing.

    Sorry, you're the one who has wrong idea in brain. Please unlearn before join yoga class.

  • (cs) in reply to Nagesh
    Nagesh:
    frits:
    Nagesh:
    True yoga is about relaxation. not pulling muscle resulting in severe injury
    You're doing it wrong! Pulling muscle should be relaxing.

    Sorry, you're the one who has wrong idea in brain. Please unlearn before watching yoga class.

    FTFY

  • Born Texas Proud (unregistered) in reply to Nagesh
    Nagesh:
    dignissim:
    Nagesh:
    Nagesh:
    Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.

    [image]

    That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.

    Is that what passes for Yoga in Indian? Man, you guys do everything half-assed.

    True yoga is about relaxation. not pulling muscle resulting in severe injury

    In that case, I am practicing "yoga" in my recliner with a beer in my hands as my Mexican slaves mow the yard outside.

  • Nagesh (unregistered) in reply to Remy Porter
    Remy Porter:
    I'm sorry guys, but I've got some really bad news. Alex has unexpectedly passed, and Mark and I need to talk about the future of this site. Stay tuned for details. Sorry.

    I recomend barial in Ganges. I teke my father there.

    [image]
  • (cs) in reply to Nagesh
    Nagesh-fake:
    Remy Porter:
    I'm sorry guys, but I've got some really bad news. Alex has unexpectedly passed, and Mark and I need to talk about the future of this site. Stay tuned for details. Sorry.

    I recomend barial in Ganges. I teke my father there.

    Hindu people do not bury, faker!

  • (cs) in reply to Remy Porter
    Remy Porter:
    I'm sorry guys, but I've got some really bad news. Alex has unexpectedly passed wind, and Mark and I need to talk about the future of the server he was standing next to, which seems to be undergoing meltdown from the fumes. Stay tuned for details. Sorry.

    FTFY

  • (cs) in reply to frits
    frits:
    Nagesh:
    True yoga is about relaxation. not pulling muscle resulting in severe injury
    You're doing it wrong! Pulling muscle should be relaxing.

    Yeah, most of you spend most of your time pulling your muscles. Make sure you have the tissues ready for when you reach the vinegar strokes.

  • Jay (unregistered) in reply to Kuba
    Kuba:
    Jay:
    If not, well: "Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for." That's absolutely insane. That assumes that you create a new table for every query you write. Can you really not imagine having, say, a "customer" table, or an "employee" table, that is used in many different places in your systems?
    Those things are orthogonal. I have a bunch of postgresql tables that are really views and have triggers on every insert, update and delete. They act as writeable views, but due to borkedness of oo.ORG's database front end, it won't ever let you do updates to updateable views, it will only do it to tables. Those tables are just views that take some extra disk space, that's all. They can be deleted and recreated as needed, of course when you first create them you populate them in a transaction from a bog-standard read-only yet temporary view. The tables that implement the relational, business-specific model are not directly accessible by the client, only the view tables are. This makes it easier to work around borkedness in oo.ORG (or any other database front-end).

    Hmm, so you're saying that rather than write a query that selects 2 fields off a table, you will instead create a new table that "simulates" a view, then copy all the data from the base table into the new table, and then add triggers to the base table to propagate all updates to the new table. Then, of course, you still have to write the "select *" query. You do this for every query, so if you have, say, 20 queries that access a given table, you will have 20 child tables, 20 sets of triggers to copy data, and some data elements copied as many as 20 times in your database. Every time a table changes, all relevant child tables must be changed, and all the triggers must be updated.

    So, disadvantages: You have to write all the data definitions multiple times. You have to write triggers to copy the data. Every schema change has to be made multiple times: to the base table, every child of the table, and every trigger that copies changes between tables. Storage requirements are multiplied many times because so much data is stored redundantly. Performance is worse because every data update has to fire numerous triggers to update all the child tables. Data integrity becomes questionable because you have created new issues of consistency between the base table and the child tables: how confidant are you that there are no missing or incorrect triggers, and that all triggers behave properly when a transaction must be rolled back, etc.

    Advantages: You can write "select *" instead of having to name the fields in your queries.

  • Jay (unregistered) in reply to Nagesh
    Nagesh:
    Remy Porter:
    I'm sorry guys, but I've got some really bad news. Alex has unexpectedly passed, and Mark and I need to talk about the future of this site. Stay tuned for details. Sorry.

    This is getting old and also boring.

    Also, a wolf has attacked the sheep! Come quick, everyone!

  • (cs) in reply to someone that would know
    someone that would know:
    WHERE clauses have always been used by the software in question and SELECT * was something you might see in code written 15 years ago.

    This "Classic WTF" post is grossly inaccurate and a hit job.

    I used SELECT * once. But I actually needed all the columns... And I still had a WHERE in it.

  • (cs) in reply to Geoff
    Geoff:
    If you are using SELECT *, and anyone changes that view/table your app is going to break. Well unless you are testing the attribute name in the record set your api returns, in which case you have accomplished nothing other than saving a few bytes in the select statement.

    If you specified the attributes, then the order of columns in the table would not matter, and additional columns could be added.

    I think you are overcomplicating it, compared to what's normally needed. For 99% of production work (at least with PHP/mySql) a "SELECT *" is exactly equivalent in terms of returned results as specifying every column name (though doing so allows you to alias them). You get the same names either way, which you "test" for by pulling them from the result set when you access (for example) a specified property of the object returned by "mysql_fetch_object($queryResult)".
    The order of fields doesn't matter at all, because the info within each record is typically accessed as an associative array / object.

    $gaurdsInfoResult = mysql_query(" SELECT * FROM adventurers WHERE injury = 'took an arrow in the knee' ")

  • Luiz Felipe (unregistered) in reply to RGro
    RGro:
    Oh come on! 'Irregular verbs' (from once existing verb-classes) are common in many european dialects.

    I dont know why they call it irregular if the great majority of it are irregular. Then in reality, they are reagular, and the regular that are irregular. But i digress. Whatever, english is better because it has little irregular verbs comparated.

  • hobbes (unregistered) in reply to Kyle H

    I can't speak for the code in dentrix enterprise, but their database design is really quite good. Always has been.

    Their reports on the other hand...but ya, the database is top notch.

  • Jeff Dege (unregistered)

    My very first day at my very first programming job, I was browsing through the code - written in C against an ISAM database library that I'd never seen before.

    About two in the afternoon I stopped in to talk about what I was learning with the lead programmer.

    I mentioned that I'd noticed that when the program needed a specific record, it would always start at the beginning, and read each record until found the one that was wanted. That seemed odd to me. "Are you sure," I asked, "that there isn't some method in the library for searching for a specific record without having to read through the whole table? He assured me that he'd read through the library documentation, and it provided no such functionality.

    When I finally found the documentation, and discovered that the 'I' in ISAM stood for "indexed", I was pretty sure that it did. Oddly enough, there were a couple of chapters in the table of contents dedicated to the topic. I ended up spending the next couple of months replacing table scans with index searches.

  • Someone (unregistered) in reply to Remy Porter
    Remy Porter:
    I'm sorry guys, but I've got some really bad news. Alex has unexpectedly passed, and Mark and I need to talk about the future of this site. Stay tuned for details. Sorry.

    TRWTF is Alex Papa-um, what was it, let's just call him Alex Papa, OK? So then, TRWTF is Alex Papa.

  • (cs) in reply to swiers
    swiers:
    Geoff:
    If you are using SELECT *, and anyone changes that view/table your app is going to break. Well unless you are testing the attribute name in the record set your api returns, in which case you have accomplished nothing other than saving a few bytes in the select statement.

    If you specified the attributes, then the order of columns in the table would not matter, and additional columns could be added.

    I think you are overcomplicating it, compared to what's normally needed. For 99% of production work (at least with PHP/mySql) a "SELECT *" is exactly equivalent in terms of returned results as specifying every column name (though doing so allows you to alias them). You get the same names either way, which you "test" for by pulling them from the result set when you access (for example) a specified property of the object returned by "mysql_fetch_object($queryResult)".
    The order of fields doesn't matter at all, because the info within each record is typically accessed as an associative array / object.

    $gaurdsInfoResult = mysql_query(" SELECT * FROM adventurers WHERE injury = 'took an arrow in the knee' ")

    Won't that query select the entire database?

  • Emperor Norton (unregistered) in reply to Cantabrigian
    Cantabrigian:
    > The system had completely Grindr'ed to a halt.

    I finded that a strange sentence.

    FTFY

  • Emperor Norton (unregistered) in reply to Cantabrigian
    Cantabrigian:
    > The system had completely Grindr'ed to a halt.

    I finded that a strange sentence.

    FTFY

  • gilhad (unregistered)

    SELECT * FROM

    I do that too, there, where I feel it is best way. I our soft, there is a lot of user input/reports on begin and where new columns are expected to be added on user wish (nearly all of them are some kind of notes importent only for users, not our SW), and we use generated forms for that, as users tends to "the report should have only A,B,C fields, but in no way D,E,F" and next week they stricly demands showing E and F, while C is not needed, so it should not be there. So I just fill object with all columns and pass it to template machine, the HTML template then shows only columns approriate for this week needs, without having me touch the main code.

    In the middle of process there are SELECTS for only named fields, as many fields never goes to calculations (like all those Comments and such).

    On the end of process again SELECT * get its place, as the end programs works only on pregenerated data from table, where all columns are important.

    Ofcourse all those selects have their WHERE clauses costructed in way, that no more filtering is needed in SW.

  • (cs) in reply to BlackKnight
    BlackKnight:
    bgodot:
    In todays episode, little Bobby Tables visits the dentist...

    I don't understand this, is it a reference to something I don't know about?

    http://xkcd.com/327/

    It's a reference to XKCD in a comic strip regarding SQL Injection attacks through a child's name.

  • (cs) in reply to Nagesh
    Nagesh:
    Nagesh-fake:
    I recomend barial in Ganges. I teke my father there.

    Hindu people do not bury, faker!

    You really need to work on your spelling and punctuation. That should have been "Hindu people do not bury fakir."

  • wkmanire (unregistered) in reply to anonymous

    Sort of like Santa Clause. It can take a task that would normally take a lifetime and turn it into a single night's work.

  • Darren (unregistered)

    Please rename this web site to 'The Whenever I get around to it - WTF'. It is hardly daily. Sick of visiting and seeing the same article.

  • Someone (unregistered) in reply to Darren
    Darren:
    Please rename this web site to 'The Whenever I get around to it - WTF'. It is hardly daily. Sick of visiting and seeing the same article.

    As I have said before TRWTF is Alex Papa.

  • Mr Clever Ideas (unregistered) in reply to facilisis
    facilisis:
    Nagesh:
    Nagesh:
    Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.

    [image]

    That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.

    Is this what passes for entertainment in India? You guys need TV!
    I'm sure his gigs are at least as much fun as Radiohead or Coldplay.

  • Oompaloompa (unregistered) in reply to Mason Wheeler
    Mason Wheeler:
    How is it even possible to learn SELECT ... FROM but be completely ignorant of WHERE?
    Very easily. It was a fairly common fallacy back in the day, for apps originally developed for good old FoxPro v2.x under DOS and later "ported" to RDBMS and web environments.

    You see, FoxPro technically qualified as a DBMS, but had somewhat awkward methods for accessing the tables. The simplest of those methods involved just that, parsing entire tables and doing filtering on the client side in what was basically a glorified loop. Which was fine because those tables were local flatfiles with single-user access, so whether filtering was done "server" or "client"-side was mostly academic. FWIW, it did provide another access method which employed indexes and something similar to WHERE clauses, for better performance, but I know for a fact that lots of mediocre FoxPro developers never found out about those.

    And then one day such a FoxPro app would come to need multiuser support. The first thing they'd try would be to share the table files over the network... which failed horribly because there was no locking and no transactions. At this point some devs resorted to simplistic, hand-made exclusive locking methods (such as the existence of a disk file) and left it at that.

    On the other hand, other devs discovered the joy of network-accessible RDBMS engines. ...Which they approached only with what they had learned from FoxPro so far ie. were perfectly content with the inherent remote- and multiuser- access offered by the engine, but completely overlooked the optimizations (WHERE, indexes etc.) because they were completely alien concepts.

    I can totally see such apps being "ported" to SQL Server with the most minimal "SELECT * FROM table" translations and client-side filtering.

  • Brian White (unregistered) in reply to Tonsil
    Tonsil:
    Trolls notwithstanding, one thing about the SELECT * approach to keep in mind: If you are joining multiple tables with one or more identical column names, the results could be unpredictable, depending on how your software handles it. For example, if the result gets dumped into a hash, perhaps the last distinctly named column is stored. If the tables' structures change, this could affect the code.

    And if you export your results to XML, CSV, etc. at some point you can blow up when you have multiple columns with the same name.

  • Wildcatmike (unregistered) in reply to no laughing matter

    You are correct about (B)Eaglesoft still being around. It is alive and well and accepting annual maintenance payments from my dad, Wildcatmike Sr., DMD. He has a single location practice with no internet access at the office. The software works OK in that environment. It has always seemed sketchy to me though. At a glance it looks like something I would have designed in college. Since he lives over an hour away, I try to concentrate my tech support visits on fixing only the exact problem he's trying to get fixed and stay out from under the hood. I'm afraid I'd end up leading a major (unpaid) software development project otherwise.

  • Bavarian Chef (unregistered)

    I used to use SELECT *...until I took an arrow to the knee.

  • A Gould (unregistered) in reply to Ross
    Ross:
    Why? Do you work at Beaglesoft?

    The sad thing is that this is not a one-off. Any supposedly production SQL that starts 'SELECT *' is bogus.

    Well, I might give you a pass if you do it as part of a daily startup. (Start your day, load in a local copy of all customers for caching, say). Actually, even then you should be filtering for active customers or something.

    But I have seen SELECT * myself, so unfortunately it's not just a bad joke.

  • Niosop (unregistered)

    Got a request in today to install some new dental software for our dental program. I thought the name sounded kind of familiar, then it hit me: we're installing this same software. I was curious as to if they had resolved the issue. It turns out they have...but not by fixing the code. Now in the documentation they list in several places, in bold letters, that WAN links are not supported.

  • AD (unregistered)
    Comment held for moderation.

Leave a comment on “Classic WTF: Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc”

Log In or post as a guest

Replying to comment #:

« Return to Article