- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- 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
You're kidding, right? This is a softball for me, and I'm a mid-level developer. Schemas aren't hard, although I usually avoid PLSQL (company policy). Generally, I'd do this as an interaction between the DB, some hosted app (for email notifications and approve/deny) and LDAP (where the org chart would probably already be). Not very hard, and not too much work.
Admin
I would have used the Chewbacca Defense.
It just don't make sense!
Admin
Meh. After the quiz has been entered, require a validation step before allowing the quiz to be used - count(*) and group will give you the number of correct answers for every question.
Admin
No cookie for you. Why allow bad data in when you can know it is bad as it is entered? This is part of the point of the question I believe. It recognizes that there may be other ways, and asks about the problems in each of them.
Admin
That's not DBA level questioning. If you can't even rough out a schema, even in a single table, to handle a scenario like that, you don't know crap about SQL or databases.
She could have gotten away with saying "I'd have a table with a field for the request user's name, and a field for every level of required approval." Just show that she knows there's such a thing as a table and that it has fields in it to store data. She couldn't even stumble through that.
Admin
Put a unique index on TBL2.AssociatedQ WHERE rightWrongFlag = true
Admin
I couldn't get them to notice me even if I'd showed up on campus with a bomb. I finally get in as a contractor, I'm here a month and they want me as an FTE. Go figure.
Admin
Because you can't enforce those rules and also allow people to move things around while building a quiz. Better to allow for this by introducing the concept of a quiz being PENDING, then VALIDATED and only exposing the VALIDATED quizes to students.
Admin
There is ofcourse much more such programs ... movie players, web browsers, firewalls ... too much to name it all.
But for someone, who knows only database the whole world looks like one big table ;-)
Admin
There is ofcourse much more such programs ... movie players, web browsers, firewalls ... too much to name it all.
But for someone, who knows only database the whole world looks like one big table ;-)
Admin
Did you actually show up on campus with a bomb? If you walk around with it, they'll just think you already work there.
Admin
Makes you wonder whether we're not in the wrong line of work,
Admin
Admin
It doesn't require that there is only 1 right answer and multiple wrong answers, nor does it require (excepting some deferred two-way constraints) that a given question have any answer at all, right or wrong.
Admin
Twenty minutes ago.
Admin
T1: QuestionID, Question, CorrectAnswerID T2: AnswerID, Order, Answer, QuestionID
A more traditional one-to-many table relationship, with the correct answerID stored in the question table. I actually like the structure because it lets you put "order" in there easily (you do want "None of the above" to appear LAST in the answer list, don't you?).
Problems include: I can't put a foreign key constraint on CorrectAnswerID, because the question record will most likely be created before the answer records. Also, how do we ensure the CorrectAnswerID doesn't point to an answer that actually belongs to a different question?
Instead of an AnswerID in the Question table, you could put an "OrderOfCorrectAnswerID", defaulted to 1, so that the first answer entered is defaulted as the correct one, until the creator of the test changes it.
Probably still not ideal, but at least as good as storing the correct and incorrect answers in different tables, which would then require trickier application logic to retrieve all answers, and randomize the display order.
Admin
Hm. option two I think will work, and is a little bit less painful:
Table1: Questions, PK id Table2: CorrectAnswers, PK qid(questions.id), answerid(answers.questionid,answers.id) Table3: Answers, PK questionid(questions.qid), answerid, seq
Or maybe that's a little bit MORE painful...
Admin
The only way to break out of that loop is to for RequestTimeOff to throw an exception (assuming it is not a macro with a break or even worse a goto in it. Note that a macro with a const_cast in it might seg-fault as you can't const_cast away for a variable that was declared as const, only one with a const modifier).
Note also that we don't know the type of supervisor but it might be a class with operator[] overloaded, and which can take any value.
Admin
That's not a bad way to go. I'm a Micosoft PM, coming in as a vendor. ("V-Trash")
Admin
The thing is, most of the time you aren't designing a database that will work on every RDBMS. You are designing a database for whatever the standard is at the company you happen to work for.
Where I work now it is MSSQL 2005, and you can use the two table layout above, create a Scalar UDF that takes the keys as parameters and checks the constraint criteria (Not more than one Y for this question, at least one Y before an N, etc) and returns a 1 or a 0. Then you can use that UDF in your check constraint on the flag field. It works fine.
So you work with the tools that are at your disposal. That answer may not work at your place of business given the software that you use, but that doesn't make it the wrong answer.
Admin
My initial thoughts to define the database schema:
Table USER Columns User ID: Employee unique sequence ID (primary key) Manager User ID: Employee's manager user ID, recursive reference to USER table. Other user meta data columns
Table REQUEST Columns Request ID: 'Request' unique sequence ID (primary key) User ID: User ID of the originator of the request. Problem statement suggests time-off, but this is applicable to any form that requires authorization. Other request meta data columns
Table (Join) REQUEST2USER Columns Request ID: foreign key to REQUEST table User ID: foreign key to USER table (where the Request ID and User ID make up the primary key). Approved Flag: true/false
Admin
I totally understand where he is coming from. Seriously, I am sick of writing "just another database frontend" after 10 years "professional". At least the 10 years before that I was having fun cracking games, mucking about with OS designs and writing hardware level stuff in assembler at home.
Time for a change, but something like that is a major mental gear-shift now. I really need to start dabbling again in the fun stuff, but after a hard day's work, I'm more inclined to just crash on the couch when I get home rather than do even more programming.
Note to kids: Don't make your hobby your job, unless you at least have another hobby to fall back on ;)
Admin
Admin
based on the title i thought it was talking about the democrats
Admin
The preview messed up my quoting. Will it stay like that? Probably. This forum software sucks.
[quote user="Chemisor"]You mean "existing, godawfully bloated, poorly designed, and hard to use with C++" implementations? I agree that MySQL certainly has a place, but not for everything.[/quote]
Wikipedia, that fantastically accurate arbiter of knowledge, lists no less than 116 databases which aren't MySQL. Of these you can be pretty sure some are lean, some are clean and some have good C++ implementations, should you actually want that.
[quote user="Chemisor"]A typical desktop application does not need all those fancy features a database provides, making them little more than bloat and inconvenience. For example, a typical desktop application will have the following differences:
Never will more than one piece of software be used be somebody to access the same data at the same time. Why would anybody want to do that?
[quote user="Chemisor"]scalability pointless,[/quote]
My music database, small by many standards, consists of 6000 entries. My girlfriend's is just 200. A magnitude of 30 times is just irrelevant.
[quote user="Chemisor"]and transaction control useless.[/quote]
Bang! Goes the electricity. Goodbye! goes your crappy media player's un-transactioned internal database.
[quote user="Chemisor"]2. Small data set. Regular people are not Fortune 500 companies and don't have terabytes of data. Most data sets are a few megabytes in size, if that. This means that all those painstaking query optimizations will not help much.[/query]
Using find to locate a file on the filesystem takes an extraordinary amount of time I do not wish to calculate. Using the optimized locate command all of 0.4 seconds.
(OK an index isn't strictly a query optimisation. Sue me.)
[quote user="Chemisor"]3. Offline. Most people don't have broadband at home. If your database server is inaccessible, the app is unusable, which is very very bad. A git-like full clone solution is a far better choice for distributed data sets in this scenario.[/quote]
I'm having to guess what this means, and I am assuming you are suggesting that a user cannot use his database-driven application when he is offline.
Of the 117 databases mentioned earlier, some don't even provide communicate over some kind of socket.
[quote user="Chemisor"]4. Run their own backups. When I want to back up a file, I want to back up a file, not a goddamn directory in some cryptically named location. I might even want to attach it to an email. Remember, small data sets![/quote]
To pick a random example:
[quote]An SQLite database is a single ordinary disk file that can be located anywhere in the directory hierarchy. ... Database files can easily be copied onto a USB memory stick or emailed for sharing.[/quote]
[quote user="Chemisor"]5.Don't have a DBA degree. And consequently not willing to spend time on weird administration tasks that require connecting to a shell-like SQL interface.[/quote]
To quote from the same source again, because it conveys exactly what I want to say and I can't be arsed to find anything else:
[quote]There is no need for an administrator to create a new database instance or assign access permissions to users. ... No actions are required to recover after a system crash or power failure. There is nothing to troubleshoot.[/quote]
[quote user="Chemisor"](Or at least that's what all the tutorials I've read do. What's with the goddamn text, people? This isn't 1976; we have GUIs these days! Or are you too cheap to make one?)[/quote]
I can't even respond to this for the sheer amount of bile present at the thought of a GUI without a terminal emulator. I'll leave it to calmer folk.
[quote user="Chemisor"]6. Goddamned text. Text-mode operations require parsers to convert to and from text data. Parsers are hard to write correctly.[/quote]
Well I communicate in English, frequently using the written word, not Egyptian hieroglyphs.
In fact I'm having a hard time seeing what the problem is here. Do you really suppose that in every case you have to write your own parser from scratch?
[quote user="Chemisor"]IMHO, MySQL is simply not a good idea in this situation. It's the wrong tool for this job.[/quote]
I would submit that MySQL is simply not a good idea.
[quote user="Chemisor"]True, but they don't provide any benefits over the simple dump-my-data-and-index solution. They are actually worse, since they have C interfaces, which will defile your pure C++ design. There is NO excuse for using plain C interfaces these days. Good design requires structure, and C can't provide any.[/quote]
C provides as much structure for your code a brick does for a house - that is to say: none.
I wouldn't like to live in a house without any bricks though.
[quote user="Chemisor"][quote user="AdT"] Bogus reason #2: When using embedded Firebird, for example, you can put the entire database in one file. [/quote] It's not a bogus reason if I haven't heard of some obscure package that allows one-file operation. Most other programmers will not have heard of it either.[/quote]
I have, and I don't use it, I don't want to use it, and I don't write code for a living.
Also we have this wonderful intarweb tool to help us research issues and acquire new knowledge.
[quote user="Chemisor"]In a single user scenario you don't need a filesystem. You just write your data as you have it in memory, in an vector or something, into a file. Writing serialization routines is not that hard. If you care about memory usage, you might implement a sliding window backend, which isn't very hard either, but in most cases you don't need one.[/quote]
You keep your filesystem-less Altair, but for the rest of us I think filesystems are a pretty nifty feature of a modern personal single-user desktop computer.
[quote user="Chemisor"]Once again, I am not disputing the need for MySQL in a huge company with terabytes of data. There you have concurrency issues, scalability issues, security problems, query performance, and all that. However, for an end-user application this is all unnecessary.[/quote]
I find it interesting that you say MySQL is unnecessary to counter AdT's suggestion that Firebird is a sane choice.
Admin
Maybe if my name was Hoop...
I'm not going to quit my (admittedly crappy) well paying full time job and move across the country for a contract position.
Admin
I prefer making short trick questions because If aI make an elaborate one I am sometimes biased on the way applicant should answer
Admin
Concurrency can exist within an application, even if just one user is present. In fact, if the application can or should do background tasks, you will depend on concurrency all the time. Databases will give you guarantees as to data coherency etc. If you don't use them, it's roll-your-own.
A single digital picture these days is about a megabyte in size. I've got thousands of them - my wife's doing, actually. With our home video collection, that's few tens of gigs of data easy. I know. It doesn't fit on two DL DVDs anymore. My email folders (raw text) are about 2 gigs now. I wish they were stored as a database (or a few) - as it is, if the indices "go bad", it takes ages to regenerate, and most email apps are pretty unresponsive when indices are being generated, or when large operations on email are being done.
Using a database doesn't imply a remote server.
There are tens of thousands of foobarbaz.sqlite.bz2 files transferred everyday by every single Fedora Core 8 system (and possibly others). They are a few hundred kilobytes in size, and contain a big heap of data about software repository contents.
If you're deploying an application for an end-user, it's your job to make sure it doesn't require a DBA degree. If you do your homework, it won't.
Text where? I don't know what databases have to do with text. You can store text in them, but not necessarily. SQL is machine-generable, at runtime, and the parser is in the database, so that you don't have to write one.
The "C" interface to SQLite is very reasonable, and it's trivial to add C++ glue on top of it if you are so intent on doing it. Maybe if you were to reuse that code across projects it'd make sense.
Using a database doesn't imply all the bogus things you think it implies. The "central locaiton" and "a whole directory" are completely bogus. Even "server-style" databases can be configured to store data in a single, given directory.
I'm sorry to say that, but you seem pretty clueless in that department... I feel sorry for "other programmers" who haven't heard of embedded databases, but their application might otherwise call for one...
The problem is that you are gonna be implementing all that: vector or something, serialization, parallel access (multiple threads, etc) who knows what else. Is indexing stuff yourself really all that much fun? Is having an exportable, mostly self-documenting file format really all that bad? If you have say an SQLite database, all you have to document is your data scheme. If it's simple, you may even skip that. If it's roll-your-own, you have to document it at the bit level. I also wish you luck with your application crashing or computer loosing power/rebooting at the wrong moment. Even a low-key database like SQLite will be robust enough in such circumstances. When you roll-your-own, I can almost guarantee you're not gonna be conservative with your data loss.
You seem like rambling with wrong preconceptios and lack of will to understand the technology you're rambling about.
Even Prevayler, which is probably what you'd like, is way more than some homegrown "serialize this or that" system. It implements database functionality (transactions, replicas, crash-worthiness) but lets you use your favourite data structures. Porting Prevayler to C++ would require some source code pre-processing like done in Qt's MOC system.
Cheers, Kuba
Admin
You hit the nail on the head! I did make the mistake of turning my hobby into a career - and didn't realize it because the stuff I did in university was fun (well, until the work piled on and I had to pull all-nighters to get it finished), and I used my summer vacations to explore what I learned making some really cool apps. Now, I use less than half of what I learned, and only the boring bits at that.
Time for a new hobby, and perhaps a visit to the career counselor. ;)
Admin
Because implementing it without something more functional than "serialize and dump" may be a bit harder than necessary.
Ok, let's say it's a simple medical application: a few screen forms with patient data, and some test results which are collected and saved. This is for a small medical practice, and data is not shared. Say a few tens of megabytes worth of data, usually. What you're proposing is that on each screen if the data is changed, the whole file has to be rewritten. That's fairly ridiculous. Unless you strive to code it well, it will always give noticeable slowdown when you go between screens.
I don't know why you insist on rambling about text formats. What the heck do the have to do with our discussion?! Databases are pretty binary-oriented and if you look at say sqlite file, there will be about as much text as you put there yourself as data. If there won't be any text data stored there, you won't see any text, nor will you have to deal with any.
I'm not saying databases are a cure-all. I'm merely saying that many applications where stubborn developers try to abstain from using databases, would benefit, if used properly. You seem to be such an example.
The whole "small datasets" stance applies to what real-life application, again? Because most people I know have unmanageably-sized email stores, picture stores, etc. Even some people's contact lists take a few megabytes on their own. And for those who always attach pictures to their contact lists, the latter soon become pretty unmanageable. An embedded database would allow to nicely store images as BLOBs (raw data) together with everything else, without having to worry much.
What has new got to do with our discussion?!
With fading away of dos-based systems, I found that I never really had a use for it. I used it daily in DOS era for sure. The need for it died away soon thereafter.
Just use NTFS.
Um, even Word has outline view. But seriously: your Google skills are lacking. Ever heard of LyX? You should have.
I don't think xmms or MS media player looks like a physical stereo.
Cheers, Kuba
Admin
Really. lex and yacc (try flex and bison on Linux) have been around and stable for over 30 years. It's blindingly easy to write parsers for a custom text format. Writing one by hand is stupid and bug prone. They even have C++ interfaces.
Using a custom binary format will make your fellow Linux users hate you--since you've just made it a pain to attack your file with my command line tools.
Yes, that's right, I said command line tools. Tons of people still use them. Particularly on Linux, since it has an amazing set called 'GNU'--you might have heard about it. Look into them, you might learn something about using a Real Computer.
If the text format is too cumbersome (too much data, performance), then the right thing to do is go with a database, for the aforementioned bug count and concurrency advantages.
Admin
Admin
I would sketch out a paper form with signature lines for each of the layers of authority.
It would be more usable and flexible than a computer solution.
Admin
Admin
That's a lot like the algorithm my boss uses:
bool MayHaveDayOff (Employee &emp) { return false; }
I still think it is broken in some ways...
Admin
Managed all three, vtash, itrash, FTE-wait-the-shares-are-worthles-sucker, and finaly back to itrash (but happy)
Admin
The real world solution would be to give the "incredibly bad programmers" an application level interface for accessing the database. This should make implementing the requirements and any future changes pretty trivial. Don't give them direct access to anything.
Admin
I'd just use up my phone joker and call Paula ^^
Admin
Admin
Well, there's no harm in being polite.
Especially not even when there's fun to be had at another person's expense.
Why? -Because it's exactly the sort of fun that a certain type of person enjoys the most..
Are you one of those.. ?
Admin
I don't know which one would be worse person to hire - Clueless Candidate or Chemisor. Somebody who has never learned anything or somebody who has learned only one thing...
I wrote my own textfile databases last time in DOS times. They managed their job, but changing the dataformat was total pain in.... With databases (I use embedded Firebird) you just run couple of update queries and that's it. And they are much faster and easier to handle. If using Delphi then there are wrapper components for database connectivity. You can have small application up and running in 30 min. And end-users don't have clue what you are using - there is absolutely no database administration.
Admin
I interviewed someone who had J2EE Expert on their resume, so when I got the the techinical questions I asked: Me: Can you tell be what type of EJBs there are? J2EE Expert: Err... Hmm... Um... Session! At last I thought... Me: Any others? J2EE Expert: Hmm... Erm... A couple of minutes pass! Me: I'll give you a clue. Entity! J2EE Expert: Yeah that's right.
I mean really, if you put J2EE expert on your resume, then you should be able to rattle on about stateful session beans, stateless ones, entity beans, message beans, message driven beans, container managed persistence, bean managed persistence, deployment descriptors, and entity relational mapping for hours right?
Maybe I should apply for a high paying job like Aerospace Engineer and just bluff my way through the interview. If I get the job and some of the rockets blow up, no one will notice as that sort of thing happens all the time (although they might catch on after five critical mission failures in a row).
Admin
Well, yes up to a point. But are you confusing Java EE with EJB? Currently I'm writing an application that uses (Acronym flood alert) JMS, JTA, JAAS, JSP, JDBC and RMI amongst other things, but not EJB.
All these are J2EE aspects so my CV says 6 years of experience with J2EE. Do you think I'm misrepresenting myself?
Admin
mark: Tammy: So exactly how would any of you have answered this question?
I would sketch out a paper form with signature lines for each of the layers of authority.
It would be more usable and flexible than a computer solution.
Unless the layers of authority are divided by geography as well. Say, US vs India vs Great Britain? Shuffling said paper around feels a bit hazardous not to mention time consuming. AND prone to disappearing.
In the company I work for it also forces promptness; supposedly the manager cannot finalize the new schedule until he has dealt with (approved or disapproved) a pending request.
Admin
Admin
Best comment ever!
Admin
I can say BuMo. Does that count? Did I ween?
Admin
This is why we need technical interviews. Sure, that's an obvious statement for most of you, but where I work, our IT Department head is someone whose IT career consists of a single VB6 application (actually, only a partial one).
Having an ego the size of [insert large item here], he's insisted on doing all the hiring of IT staff himself, and as the sole interviewer.
Admin
Your solution is the best one, IMHO.
For your first problem (can't put a foreign key constraint on CorrectAnswerID), just use a constraint that is enforced at commit time rather than insert time, and insert the question and right answer in the same transaction.
Admin
The id columns are, of course, not strictly required, but convenient. The two-way referential integrity requires an ALTER TABLE to establish. I'm assuming a (unique foreign) key column can be null, because I seem to recall it can. The hole is that this design allows for questions with no right answers (or alternatively answers with no questions). To require them, you would need a capability to verify RI only at the end of a transaction, and I don't really know how well that's supported.
Fixed answer: table "question": id(auto, pk), text(uniq, req), rightanswertext(req) table "wronganswer": question(fk question.id, req), text(req) constr uniq(wronganswer.question, wronganswer.text)
This solution conveniently avoids the two assumptions in the previous design. The hole here is that this design allows for identical wrong and right answers for the same question. This would be simple enough to fix with a constraint query, but then, that's a bit of a cop-out considering the RI spirit of the question. I might look into the RDBMS manual for any possible mention of shared indices.