- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Because you can get SqlServer Express for free and better results + tools.
Admin
True yoga is about relaxation. not pulling muscle resulting in severe injury
Admin
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.
Admin
Don't worry. Only successful companies need to deal with adding columns to tables :P
Admin
The table would not need to be indexed to resolve the problem of pushing megabytes of data across the wire to the remote office.
Admin
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.
Admin
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.
Admin
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.
Admin
This is getting old and also boring.
Admin
Admin
Sorry, you're the one who has wrong idea in brain. Please unlearn before join yoga class.
Admin
Admin
Admin
I recomend barial in Ganges. I teke my father there.
[image]Admin
Hindu people do not bury, faker!
Admin
FTFY
Admin
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.
Admin
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.
Admin
Also, a wolf has attacked the sheep! Come quick, everyone!
Admin
I used SELECT * once. But I actually needed all the columns... And I still had a WHERE in it.
Admin
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' ")
Admin
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.
Admin
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.
Admin
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.
Admin
TRWTF is Alex Papa-um, what was it, let's just call him Alex Papa, OK? So then, TRWTF is Alex Papa.
Admin
Won't that query select the entire database?
Admin
FTFY
Admin
FTFY
Admin
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.
Admin
http://xkcd.com/327/
It's a reference to XKCD in a comic strip regarding SQL Injection attacks through a child's name.
Admin
You really need to work on your spelling and punctuation. That should have been "Hindu people do not bury fakir."
Admin
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.
Admin
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.
Admin
As I have said before TRWTF is Alex Papa.
Admin
Admin
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.
Admin
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.
Admin
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.
Admin
I used to use SELECT *...until I took an arrow to the knee.
Admin
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.
Admin
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.