Quick, give me a unique/challenging MySQL problem!!!!

[MutantJohn]

I want to learn MySQL because I want a job in programming. You think being a mesh generating boss (I finally kind of understand the Shewchuk predicates [google those, it'll blow your mind how good he is at programming]) would be enough but alas, all I know is the LAP stack and a lot of applications require MySQL specifically.

I want to know the M part so I'm a full-fledged web guru.

I'm reading a tutorial now so I'm seeing basic commands but these are all meaningless to me because I don't have an application.

So, in your guys' years of experience, what were some challenges you solved with MySQL or what were complexities of the language that you encountered that were difficult? I'm trying to get a feel for how tough MySQL is, how it's used effectively, what are its shortcomings, etc.

Or was the only hard part building the applications themselves? I can see writing complex CGI scripts or AJAX calls being difficult (thank you guys for your help on that too) but what's the big deal about MySQL?

[phantomotap]

I want to learn MySQL because I want a job in programming.

O_o

Great, my eyes are bleeding.

I'm reading a tutorial now so I'm seeing basic commands but these are all meaningless to me because I don't have an application.

The "MySQL" thing you keep referencing is just a database engine built using SQL for communication with the engine. You'll face plenty of quirks, but you'll find ways to work around all of the quirks. You are either using "MySQL" as a structured database engine or the wrong tool for the job, but using a database engine isn't actually a solution to anything any more than regular expressions.

Do you have some structured data you need to store, search, and mutate? You might have a fit for "MySQL", but the mechanisms you use communicate and structure data is just a tool you'll be using to solve a problem which itself presents the problem of how you need to communicate and structure data.

In other words, adding "MySQL" to an application stack just answers certain questions on the way to solving a problem. ("How do I store my data on disc for later use?") You require the application because "MySQL" is a part of the application.

You should finish off the basic--sins and syntax--tutorials. Once you have the basics down, write an application using "MySQL" for the data.

You could write an address book.

You could write an inventory program.

*shrug*

You'll be repeating all those sorts of applications you've already written a dozen times, but you'll be using "MySQL" as a fragment of the implementation in the same way you might have learned communicating with sockets or storing data in files.

Once you have all that done, you find a problem you want to solve. If the application benefits from what you've learned from repeating all those exercises with "MySQL", you can start worrying about designing a database for the data the solution will require. As is likely as not, you'll just be misusing the tool if you reach for "MySQL" because "web guru".

Soma

[laserlight]

I'm reading a tutorial now so I'm seeing basic commands

I won't begrudge you learning the syntax of MySQL's SQL dialect and such because you will need it to directly use MySQL after all, but perhaps you should also look into database design, like the notion of the entity-relationship model and database normalisation.

You'll face plenty of quirks, but you'll find ways to work around all of the quirks.

It has its own quirks, but does using PostgreSQL instead count as a work around?

[phantomotap]

It has its own quirks, but does using PostgreSQL instead count as a work around?

^_^

That's is the solution I recommend.

Soma

[MutantJohn]

Yeah, I've mellowed out a tad now and I'm starting to read the wikiepdia entries on DBMS models. I just don't get why I see MySQL/SQL so freaking much on job applications. Like, that's the only thing they care about nowadays.

Maybe I'm just looking at the wrong jobs...

[Nominal Animal]

I tried to think of a good problem, maybe something related to user authentication and access control using encrypted passwords (ROT-13, of course), but I suddenly got an idea for a new phone app instead and got diverted.

Now that phones have pretty good graphics capabilities and refresh rates, an app that flashes full-screen advertisements but only for one frame, would be the phone carriers wet dream. Just think of the monetization possibilities! Perhaps use the front camera, too, to track the users face, for picking the best moment to flash the provided content. If the camera resolution is good enough, you could track their eyes for optimal timing; for large logos, peripheral vision works best. The content doesn't need to be opaque, replacing the entire view; it could also be something like an emboss effect with tinting.

Oh, yes.

I wonder why no-one has named their SQL engine "Deliverance" yet.

[phantomotap]

Yeah, I've mellowed out a tad now and I'm starting to read the wikiepdia entries on DBMS models. I just don't get why I see MySQL/SQL so freaking much on job applications. Like, that's the only thing they care about nowadays.

[Edit]*sigh*[/Edit]

O_o

You might should learn from cynical jerk. When you see more than two or three experience requirements, the requirements are either largely fictional (You should apply anyway on the strength of your skill in the requirements that seem reasonable for the position.) or the role is a temporary clus******k (You don't want such a job unless you are desperate.) that exists solely to fill multiple roles in a heavy scramble to match an impossible milestone. Sure, a lot of web jobs usually invoke "five years experience administering databases"; if you looked hard at many of those roles, they actually just want someone competent enough to play seconds on "Drupal" without typing "drop *" or similar.

Soma

[laserlight]

I just don't get why I see MySQL/SQL so freaking much on job applications. Like, that's the only thing they care about nowadays.

Just a few years ago "NoSQL" databases were all the rage.

I think learning the fundamentals of relational database design is a good skill to have in the long term. Learning basic SQL syntax to do CRUD operations and joins will be a good background to have. Beyond that, if you need to know more should you get stuck, you can always read the documentation and search the Web. Besides, you might end up using a framework with its own database abstraction layer, in which case you might not even dip into SQL at all, and maybe the database tables will get generated from classes in your code, or even from some kind of alternative method of specifying the schema.

[Alpo]

[Edit]*sigh*[/Edit]

O_o

You might should learn from cynical jerk. When you see more than two or three experience requirements, the requirements are either largely fictional (You should apply anyway on the strength of your skill in the requirements that seem reasonable for the position.)
Soma

Is it a "we can hire you for cheaper, because you don't meet all the 'requirements'" thing? I remember reading an article that this was a trend with employers, where they put higher requirements on entry positions for that reason.

[Mario F.]

Just a few years ago "NoSQL" databases were all the rage.

They still are. You take a look a tech books being released since the last 2 years, or the developments in new DBMS, and you'd think SQL has been deprecated. Like everyone in the industry is now developing Big Data applications. Only no one really is because Big Data is still largely a niche development area. As it should.

Of course, there will always be someone who confuses database size with NoSQL. Big Data is an an unfortunate choice for a term, it seems. And it doesn't help that the blogging idiots in the industry rage on about MongDB, Cassandra, Riak, or HBase and the often misquoted Hadoop, without providing any context at all as to what really means to be using NoSQL storage models, beyond that of the number of records.

[Carnotter]

Good answer, laserlight.
Try learn the theories how to design structures from available information. This is good one. After that: go and check an existing database to see if it's well designed or not, and if it is not the case, reconstruct it without loosing a byte of info.

[MacNilly]

They still are. You take a look a tech books being released since the last 2 years, or the developments in new DBMS, and you'd think SQL has been deprecated. Like everyone in the industry is now developing Big Data applications. Only no one really is because Big Data is still largely a niche development area. As it should.

Of course, there will always be someone who confuses database size with NoSQL. Big Data is an an unfortunate choice for a term, it seems. And it doesn't help that the blogging idiots in the industry rage on about MongDB, Cassandra, Riak, or HBase and the often misquoted Hadoop, without providing any context at all as to what really means to be using NoSQL storage models, beyond that of the number of records.

To me SQL is just a language to describe data thats in a relational model -- whether that data is stored binary, XML, or JSON doesn't matter, except for the efficiency. I dont see any benefit of the whole "NoSQL" thing, except that maybe people just hate learning about RDBMs and SQL -- its a heck of a lot earier to use JSON.