@blakeyrat said:

Complaining about having to join 5 tables in a single query-- joining tables is what relational databases do! That is their raison d'être! (Not to say that that address field schema made sense, but complaining about joins is somewhere between "completely missing the point" and "incredibly petty."

Welp, thread over, I guess. I didn't realize there were never any downsides to joins. Thanks for the protip!

I'm off to refactor my FAQ table and abstracting away the questions so each question has a LetterID and SequenceID which I can use to reconstruct the English text. That way, if the letter A ever changes, I can fix my entire FAQ with one database update!

Hmm, perhaps I should have a CharacterType field too, with a foreign key to either the letter table or the punctuation table. That would be more flexible!

Complaining about joins is petty! You heard it here first, folks!

@PJH said:

@JeffS said:

There is no schema to see.

Rubbish. mysqldump or whatever equivalent there is for your database product. Just tell it to just spit out the table schemata and not the data.

Assuming constraints, primary keys, foreign keys are defined, and further assuming a sane naming convention, you might be able to decipher the schema.

Sadly, this database has none of those...

@blakeyrat said:

@JeffS said:

@Mole said:

Unless of course the category is an enum thats processed later[...]

Category is VARCHAR(25).

Is this a WTF yet?

Ah! Now you're definitely venturing into WTF territory. At the very least, it should be NVARCHAR. ;)

OK, you owe me a new keyboard. There's hot coffee all over mine now.

@blakeyrat said:

Please. I've seen databases designed by "developers who have been there before." They've inevitably shit. Most developers hate SQL, have no clue how relations work, and create shitty database schemas. They treat your expensive high-tech database server as some kind of high-capacity copy of Excel. Not all. But most.

Please. I've seen databases designed by "professional DBAs" that are inevitably shit. Did I tell you about the customer table that had a separate address table, and the address table had a separate "AddressLine" table (to account for PO box, Suite number, or other delivery information because AddressLine1 and AddressLine2 would violate the holiest-of-holy normalization rules) and the address table had the city in a separate "city" table and the states were in another "state" table, so I had to join like five tables just to get the lousy address. This is good design? Throw in some XML, and we have an enterprise system!

Thanks to that structure, if Cincinnati, Iowa and Cincinnati, Ohio ever decide to change their names at the same time to the same new name, it's only one database update! And that's savings you can take to the bank!

Look, I agree a database shouldn't be some stupid data store of opaque varchar blobs. But you have to agree that DBAs can shit out some real crap, too. And my little FAQ example is real crap.

@blakeyrat said:

@JeffS said:

I'll give you that a one-to-many relationship between Q and A might be useful instead of a straight one-to-one, but, unless you're TopCod3r, you can't give me reasonable examples for the other possibilities a many-to-many allows.

I gave a couple of them near the top of the post. And like I said there, the only combination that doesn't make sense is having an answer with zero questions-- of course if they coded the database correctly, there's a Constraint installed to prevent that.

Why would I want a single answer shared among multiple questions? (Oooooo, I know... like an answer "No" so if we ever want to change all our "No"s to "Yes"s, it's just one database update!)

I'm starting to think the WTF is you. Anybody who designs a space shuttle when requirements call for a paper airplane...

What's that old CS quotation about premature optimization?

@Mole said:

Unless of course the category is an enum thats processed later[...]

Category is VARCHAR(25).

Is this a WTF yet?

@Mole said:

Can we see the schema? I'm guessing not, but it doesn't hurt to try :)

Bwaaaaaaaaaaaaa ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha hah!

Good one, Mole! Yeah, and I'll also show you the design documents, the entity-relationship diagrams and the unit tests! Then I'll show you the tooth fairy!

Our project has none of these. There is no schema to see.

...schema... lolz....

@Mole said:

Not a WTF. Rather, a database designed by someone who has done it before rather than a web designers first attempt at SQL.

Nope, it's actually a WTF.

It's a database designed by some self-proclaimed database guru who read an article about data normalization, instead of a by a developer who's been there before.

Look, flexibility is good, and future development and maintenance should be considered, but it can be taken too far, which happened in this case.

I'll give you that a one-to-many relationship between Q and A might be useful instead of a straight one-to-one, but, unless you're TopCod3r, you can't give me reasonable examples for the other possibilities a many-to-many allows.

@frits said:

Sounds like it's modeling real life.

@Zimzat said:

I don't see why multiple questions couldn't have the same answer depending on context (or I'm thinking more along the line of a knowledge database type scenario).

You guys are a bunch of over-engineering engineers!

Do you ever surf the web? Do you see FAQs anywhere in your web travels? It's a simple question-and-answer mechanism employed since the early days. This is not Wikipedia or the smegging Microsoft knowledge base, ok? FAQ-- Frequently Asked Questions.

Q. Do you ship to P.O. boxes? A. No.

Q. How do I recover my password? A. Follow this link on the Profile page.

Why must you over-complexify this? You remember that TDWTF a few years back about keeping a biker's hands warm in cold weather?

So, our web portal app thingy has a FAQ section, and the questions and answers fed from the database... that way, we can add, subtract or edit questions from a simple back-end admin page.

Here's the (abridged) query to get the question-and-answer list:

SELECT
 FAQ.Category,
 Q.QuestionText,
 A.AnswerText
FROM
 FAQ
JOIN Q
 ON Q.QuestionID = FAQ.QuestionID
JOIN A
 ON A.AnswerID = FAQ.AnswerID

For those not versed in SQL, or not inclined to parse this query, here's the nut--

It's a many-to-may relationship between questions and answers. Each question may have multiple answers, each answer may have multiple questions, answers may be shared among questions, and multiple questions could have the same answer. This structure also allows for questions without answers and answers with questions. It's totally flexible, and totally stupid.

It's not failure, it's worse than failure!

@MasterPlanSoftware said:

@rdrunner said:

wanted to know why they have stored my password in an retrievable format

 

Did you want them to NOT be able to retrieve it? How did you think authentication would work?

Try hash.  Good stuff.

Hash with salt, even better.