Feeds

back to article SQL survives murder attempt by mutant stepchild

Silicon Valley likes nothing more than to fetish the Next Big Technology Trend, be it cloud or NoSQL or scripting languages. The problem is that the real world moves much more slowly, and has very different considerations fueling its technology decisions. Perhaps nowhere is this clearer than in the technology media's infatuation …

COMMENTS

This topic is closed for new posts.

Page:

Thumb Up

Too true.

Such a blindingly obvious conclusion that it almost didn't need to be said. Almost.

Every so often, someone needs to point out how much of an echo chamber Silicon Valley is, and the tech reporting to go with it.

The real world of enterprise IT is a dull place of low expectations and glacial change.

28
1
Anonymous Coward

"how much of an echo chamber Silicon Valley is"

True - see original article, for example.

3
0
Silver badge

SQL or relational?

Are you talking about the relational DB model or SQL, as in the language?

There has been a long period in IT history now where the relational model has dominated the industry.

It is used in a lot of places where it just doesn't fit well. Anyone who has built different systems involving databases will know this. Where it works well, it works very well. Where it doesn't it is a right royal pain.

Recently we have seen a bit of a backlash against this status quo. Mainly this is arisen from the changing landscape of storage needs. Structure is much more flexible and doesn't necessarily lend itself to the more fixed table-based paradigm.

We should also not confuse the non-relational way of doing things with forgetting the ACID aspects that most people associated with the relational model. You don't HAVE to throw all the ACID benefits away just because you try a model that is not relational. It's just that in many cases, that is happening because of the applications where non-relational DBs are being tried.

I see the changing culture of not assuming the relational databases fits all cases a good thing. People are re-exploring structures and ways of doing things from 20 or more years ago, from before relational DBs took off.

5
2
Silver badge
FAIL

Toxic stuff

Most, if not all of these NoSQL thingies throw ACID out of the window. The problem is that the aren't meant to be substitutes for RDBMSs, but more for non-relational stuff that doesn't quite fit the relational model. However, it's being sold as an "SQL Substitute" which is wrong, and whoever goes ahead and implements this just out of hating SQL is going to have this bite back!

7
2
Silver badge
Coat

I'll accept that the relational model does not alway map well to all tasks

but (as you point out) it maps DAMN well to a few tasks. the problem I'm seeing at the moment, is that all this non-relational hype is sometimes (but not necessarily always) just a cover for poor design.

Proper relational databases (sit down MySQL, you don't get any credit here. The lack of proper enforcement of relations in MySQL is IMNSHO one of the biggest issues this is a backlash against. MySQL is all the disadvantages of relational DBs, with none of the benefits.) means the DB is actually checking the data for you. Did some yahoo try to say John Smith drives a cat to work? Well "cats" are not in SillyDB.AutoMfgs, so a PROPER relational DB refuses to add it.

I've done some experimenting with redis, and it is nice for some things (session data is a great example), but for many things the advantages of relational are really hard to ignore.

mine the one with a PostgreSQL copy in the pocket

10
1
Ru

sold as an "SQL Substitute"

Sold as an RDBMS substitute, I think. I imagine if you plotted a graph of 'number of RDB instances' vs 'number of features of an RDB used' you'd see that the vast number of deployments are very small, very simple, and only use fancy things like 'foreign keys' because they were crufted together by someone who did a compsci course once.

For the sort of people who have no idea what data integrity might mean, or use cursors instead of select, NoSQL would seem to be a perfectly adequate replacement.

Me, I've always liked lightweight transaction-capable embedded databases like BDB and ESE. But that isn't cool at all.

1
0
Anonymous Coward

Databases on ACID

It's not so much "throwing ACID out of the window": it's that many of these databases take a different view on the CAP triangle (Consistency - Availability - Partition Tolerance), focussing on Availability and Partition Tolerance, and allowing consistency to catch up later.

This is exactly what you want when building a large-scale web service.

Representing your application's data as a single JSON object (say), rather than a join across 5 tables (say), is something of a side effect of this. It means that you have a blob of data which is internally consistent and tied together, which you can resolve against the rest of your database later.

3
0
Anonymous Coward

@Oninoshiko

Given how much better MySQL's documentation is than PostgreSQL's, it amazes me that anyone who claims to use both can get it so wrong.

"The lack of proper enforcement of relations" Where? When? Did you look at the manual?

Historically, MySQL defaulted to MyISAM tables which are not ACID compliant. If you read the first few pages of the manual, you knew to use Innodb tables which are ACID compliant (if that's what you want).

These days, MySQL uses Innodb by default.

This also highlights a problem with this article: the real argument is about using or otherwise a RDBMS. Whether you want to use SQL to query your data is a separate question.

2
3
Stop

RE: "Sit down MySQL"

Nobody with any real experience used the MyISAM engine in MySQL anyway - they all use InnoDB, which is a perfectly good relational engine with full ACID compliance.

As you aptly demonstrate, there are still lots of people spreading FUD about MySQL though. They're very similar to the people suggesting that NoSQL solutions are a drop-in replacement for a proper RDBMS for all tasks when you think about it though - lots of words but very little evidence.

[I must admit I gave up on MySQL in favour of Postgres too, but that's not the point here]

2
0
Facepalm

Once you start using InnoDB...

...the benefits of MySQL go away. With full relational constraints imposed, it's slower than Postgres. Not to mention that "relational constraints" in the MySQL world doesn't necessarily mean the same thing it does in real databases. Truncation (i.e. modifying data) rather than raising an error is the norm in the MySQL way of thinking. Yes, there's "strict mode" but that's enforced client side, not server side. Wanna dump some crap in your database? Turn off strict mode and have a ball. Or use "INSERT IGNORE".

Triggers? Make me laugh. Constraint checking? "Parsed but ignored". Transactional DDL? Nope. Transaction locking behaves "oddly" (but, I'll grant you, predictably). Inserting nulls into non-null fields? Check.

I could go on. I usually do. Facepalm because that's what MySQL is.

8
0

better yet

Better yet you can mix and match your tables to suit... if you need ACID complaint RDBMS then use a load of innoDB tables - but if you've also got fairly simple non-relational data in there as well, you can just chuck in a load of MyISAM tables for that data - which gives you the option to run fulltext searches on those tables.

PostGres is a better RDBMS but MySQL is like a kind of handy little SQL toolbox which you can beat with a monkey wrench until it best fits your needs... like many things on the web, it's not the cleanest, most technically "pure" implementation going - but it's flexible, reasonably fast, easy to configure/maintain and resilient.

1
0
Trollface

Re: @Oninoshiko

"Given how much better MySQL's documentation is than PostgreSQL's, it amazes me that anyone who claims to use both can get it so wrong."

Wicked sarcasm, there.

1
1
mcv

NoSQL solves a different problem than RDBMS

That's exactly what I came to say. NoSQL DBs aren't meant to replace relational databases, they're trying to solve a completely different problem. Relational databases with their ACID are meant for keeping rigid, highly structured data consistent. NoSQL databases are for storing data where size, speed and scalability are far more important than consistency.

Google, for example, uses their BigTable for matching ads with your surfing behaviour -- if it messes up every once in a while, nobody will even notice, let alone care. But for their paying adword customers, you can bet they're using a relational database. There, accuracy and consistency is far more important. It's the difference in scaling requirements between tracking billions of internet users, and tracking maybe millions of paying advertisers.

Few small companies are likely to have to worry about such Google-scale issues, so for them RDBMSs are fine.

2
0
Trollface

Usual mess

First of all, the (yes, there's only one) Relation Model has nothing to say regarding ACID properties which belong to transaction theory. Of course any real-life implementation will have to deal with those properties but that is another story.

Anyway, although saying that "the ACID aspects that most people associated with the relational model" is correct (most people do the association), saying that "You don't HAVE to throw all the ACID benefits away just because you try a model that is not relational" doesn't really hold unless you say "... just because you try a database management system that is not one of the currently (badly) implemented relational database management systems".

You may think that I'm just being picky, but I'm convinced that most problems lie exactly in a common misunderstanding of basic concepts.

One of the big advantages of the Relational Model is exactly that it doesn't get into the physical implementation details with the consequence that you don't have to change your understanding of the data just because one DMBS implements row-in-pages storage vs. columnar storage vs. any other physical implementation anyone may come up with.

Of course at a certain point the conceptual model (relations) has to come down to a logical model (e.g. ER) and a physical implementation (tables) that deals with concurrent updates (transaction theory).

However, most people simply start singing the inflexibility mantra of the model, which indeed is a problem, but you know what? IMO the truth is that in many (most I would say) cases, it is not an "open-schema" kind of a problem, it's just that people want to build the system without really putting any effort into understanding the data upfront. Which will always bring problems later. If you ever worked in a BI or MDM project, or anything that has to do with data quality, you know exactly what I mean.

To say it in another way: one thing is to struggle to keep up with a changing schema, another one is bothering only about writing code without any will to understand the schema first.

Information has a schema, or meaning, otherwise no one would be able to interact with it. Not bothering too much with a precise definition of the schema only means a higher provability of posing the wrong questions and/or getting wrong answers (paradoxically a lot of practitioners may get correct answers to wrong questions by hammering around with the syntax of the questions but that's also another story...)

And yes! A lot of people are simply re-discovering bad wheels that were dismissed for good reasons. Part of the problem is that they don't want to educate themselves and part is that they feel understanding data as a boring thing compared to coding some stupid algorithm to support some already known structure.

This is one side of the SQL vs. NoSQL debate (schema vs. no schema), the other one boils down to the ACID vs. CAP vs. Nothing approach but I would say that a similar reasoning applies. It's simply easier to go down the "eventual consistency" route than fully supporting ACID properties.

It's perfectly fine to have Facebook's photos partitioned because if someone can't see the latest wild party photos, he will simply move on (and maybe check later). It's not the same thing with a lot of other scenarios though.

So in the end I sort of agree with you, it all boils down to really understanding the problem at hand and choosing the right technology. However, this is not what I see. I don't see the "understanding" part. But I see a lot of uneducated people fiddling around with the latest technologies du-jour that are really vintage fashion.

2
0

How can you possibly...

...say that MySQL docs are better than PG's - have you had to use either?

MySQL's is bloated badly.

1
0

Reformed

You're worse than a reformed alcoholic. Sucking the fun out of the world and convincing it that it doesn't need or want passion.

Did you get slippers and a pipe when your turned raving conservative Matt?

3
6
Thumb Up

good article

you win 10 points

1
2
Bronze badge

really?

"No, Microsoft became a technology behemoth by relentlessly lowering the skills bar for application developers and IT administrators. Unix and other competitors were comparatively hard, if more secure/powerful/whatever. Microsoft was easy."

No, Microsoft became a technology behemoth by providing a usable enough and affordable platform for the mass market. I don't know that it was especially harder to write decent GUI-driven apps to run on a UNIX box than on Windows. I suspect that a successful application was likely to sell a few tens of thousands on Unix, a few million on Windows

5
2
Silver badge
WTF?

what you said...

and what he said.

it's like the same thing dude!

where "usable enough" equates to "lowering the skills bar for application developers"

and "tens of thousands on Unix, a few million on Windows"

is the state of affairs _after_ M$ became a tech behemoth

0
0
Silver badge
Windows

You couldn't pay for it on the Unix

1) Expensive hardware

2) Expensive OS (Minix doesn't count)

3) Expensive GUI (shell out extra for the Motif Widget set an a C compiler? Sure)

4) Expensive Applications ("get a quote from our salesdroid by call 1-800-military-industrial-only")

5) There was no O'Reilly or amazon and a rare Internet Access Point so... no docs!

Lock in? Hell yeah.

4
0
Silver badge

likely to sell a few tens of thousands on Unix, a few million on Windows

your post is confused, you're basically saying microsoft was more successful because microsoft had a bigger install base. So they were more successful because they were more successful...

Besides which, for what you're saying to be true UNIX would need a VB like language, that's what made developing on microsoft platforms easy.

Of course, dodgy business practices certainly helped as well....

1
0
Bronze badge

Re: really?

The problem (for a certain, very loose definition of "problem") is that there's no VB for UNIX.

0
0
Linux

Re: likely to sell a few tens of thousands on Unix, a few million on Windows

"Besides which, for what you're saying to be true UNIX would need a VB like language, that's what made developing on microsoft platforms easy."

There have been such things on UNIX for decades.

"Of course, dodgy business practices certainly helped as well...."

Behold the elephant in the room. Unbundle Windows now!

1
1
Stop

Re: There have been such things on UNIX for decades.

Such as?

0
0
Coat

Actually they did...

But it didn't end well:

http://ars.userfriendly.org/cartoons/?id=20110802&mode=classic

0
0
Anonymous Coward

Errr

"Microsoft didn't become the desktop king and a strong contender in servers through anti-competitive tying arrangements. No, Microsoft became a technology behemoth by relentlessly lowering the skills bar for application developers and IT administrators. Unix and other competitors were comparatively hard, if more secure/powerful/whatever. Microsoft was easy."

[Using] Microsoft is not "easy" or especially productive or effective for that matter. It is the combination of marketing and monopoly has made MS so pervasive and an inevitability for some.

1
1

Seriously?

----

[Using] Microsoft is not "easy"

----

Seriously? MS make good tools with pretty good documentation - here's your 30 minute challenge. Create a basic Windows app with a GUI using:

1: Java on Netbeans with the Netbeans platform (or just raw Swing if you like).

2: C#.NET on MS Visual Studio 2010 (Express edition is free for personal use).

In the long run your Java project may well be better, it'll certainly be more portable... but to even get the basics done is going to take you considerably longer. C# is actually staggeringly easy to take your first baby-steps in and have something running on the screen... Java, yeah, not so much.

So from a developer/programmer perspective, sorry, MS software actually IS easy and productive and normally reasonably well documented on MSDN.

3
0
Ru

Sorta

Very few GUI libraries are easy or fun to use... I'd go as far as saying that none are or ever have been. MS at least managed to be competetively awful, or marginally better than some atrocious alternatives.

That was good enough, back in the day.

0
0
Thumb Down

easy

It is easy, but only for small networks and small data sets. When either your network or data grows it's too late, you already swallowed the hook, line and sinker.

Most people think that administrating a MS Server is just as easy as their laptop with Windows 7 Home Edition. "It has a gooey, so it *has* to be easy".

1
0
Silver badge

Actually, he's looking at the wrong market segment,

and you are confusing what Windows is, with what MS was when it came out. Back then it was:

Option 1:

Buy a mini-computer from IBM/DEC/Wang. Sign a 5 year contract for service and support. Pay IBM to develop an accounting application for your company. Spend 6 to 9 months customizing installing and debugging the software. Repeat for changes as necessary. Cost: [classified, but rumored to start at $50,000K and known to run into the millions depending on the size of the application and length of contract].

Option 2: Buy an IBM PC, preloaded with DOS. Buy Lotus 1-2-3. Cost: $5,000-$10,000. Have your accounting staff create the spreadsheets necessary to support your business: sunk cost so it counts as free.

The software developers and their problems never really entered into the picture.

1
0
Paris Hilton

@CD001

Easy.... up to a point.

For example in MickySoft VB for applications, if you want to open a file selection window you still have to call the windows API directly. You may as well be programming in 'C'.

The quality of mickysoft helpfile documentation has declined over the years as well, IMHO there was a time that the help files supplied with VB, access etc were of sufficent quality to learn VB programming. Now adays they are barly an aid memoir.

Mickysoft dumbing down - the ribbon, mickysoft makes something more annoying that the animated paperclip.

Paris, easy... up to a point.

1
1
FAIL

mapreduce

So you search for "mapreduce" and you think that equates to the take up of "NoSQL" datastores ?

NoSQL datastores are obviously in use in many companies for specific roles. "mapreduce" is but one part of the capabilities of such datastores.

2
0

Microsoft is easier

Having programmed for many years in both .NET and PHP, my personal opinion is I find PHP easier. I still like the idea of being in control of exactly what gets sent to the browser. I made a choice to cross from .NET web application development over to PHP, because I like the language, it's more compatible with my preferred platforms and I know I am not going to be forced to retrain every few years or be totally dumped in favour of the next big MS tech. I used to work in the NHS, where the management thought PHP was not for big professional applications, I thought Facebook?

3
0

Re: Microsoft is easier

Nope Microsoft isn't easier, and never was. They had great marketing, and once in a monopoly position they exploited it with little restraint from the authorities. As MS achieved domination, their shell scripting support was a joke. VB was predated by Tcl/Tk as well as other high level languages and toolkits that enabled the writing of GUI apps far more easily on Unix than Windows.

As for PHP - part of the reason the NHS IT program is such a disaster is down to the use of it (I knew several people working on the BT part of the contract who passed on many horror stories). As for Facebook, they use a subset of PHP for a part of their system, and they wrote their own implementation because the existing implementation and frameworks were so buggy and awkward to program well for.

2
0
Ru

Hurgh

I've generally found that ASPX is an adequate development platform... the biggest issue for me was the requirement to use IIS which is a bloody awful webserver. The only nice thing I have to say about PHP is that it is quick... I'd much rather use any other language for development however, as its a horrible language with disappointing libraries. Perl and Java and Python rather put it to shame, and have a fractionally higher bar to entry.

0
0

Easier to get wrong

Funny - I spend most of my time chopping and changing between PHP and C#.NET and I prefer C# (oh, so much more when it comes to getters and setters).

PHP may be easier to hack about and get results... but that doesn't means that those results will be good - it doesn't mean they won't but it's much easier to go very, very wrong with PHP. I would love it if PHP was strictly typed (for instance) but then, of course, it wouldn't be PHP, but I hate having to ensure that every variable is set and properly typed inside my classes to ensure a cleanliness in the API.

Yes you can strictly type objects as method parameters BUT that's less useful than you might think without the language itself being strictly typed. Say you want to attach a multimedia object to a product object (as an example) - and you've three flavours of multimedia object, Image, Video and Audio.

Your PHP function may now have 4 different method calls, like:

setMultimediaAudio(Audio $oMM) { ... }

setMultimediaImage(Image $oMM) { ... }

setMultimediaVideo(Video $oMM) { ... }

getMultimedia() { ... } //mixed return

To keep the API clean in PHP you're actually better off NOT enforcing the type because it generates additional getters and setters - you can't _really_ overload the methods without resorting to some fairly dirty hacks like __call().

Because C# (and any other strictly typed language) are strictly typed they allow for "proper" method overloading - many methods with the same name that accept different parameters; which nicely enforces your types AND keeps the API clean.

In PHP it's not really possible to do both well without having to write additional type validation code.

Oh... and I also hate some of PHPs inconsistencies "$_EVERYTHING oh, except $GLOBALS", there's a whole host of weird naming systems (off the top of my head I can think of 3 different terms used for string escaping, addslashes, mysqli_real_escape_string, preg_quote, why not say escape_string(), mysqli_escape_string() and preg_escape_string()? ).

PHP suffers from being a procedural language which has had OOP hammered onto it, built by a committee of Perl fans with a lot of legacy code ... we end up with procedural calls (like mysqli_real_escape_string()) being fudged onto the OO structure which gives some odd looking method calls mysqli::real_escape_string() alongside newer more object oriented functionality like DirectoryIterator::getPath() and some truly strange decisions like using '\' for namespaces - namespace \myApp\DB for instance.

C# seems like a haven of sanity by comparison *sighs*

1
0
FAIL

Not a DB

In what way is MapReduce a DB? In most use-cases SQL will be used against a relational datastore to return data in under a second... MapReduce will be ran as a batch job to churn through terabytes/petabytes of data and apply an algorithm to 'reduce' or extract information of interest from semi structured or unstructured data. It will return in the timescale of hours or at most tens of minutes, Hadoop is pretty poor at quickly returning results as it kicks off JVMs to service the job.

Now comparing to Cassandra et al is maybe more of a reasonable stretch given it is a hierarchical key-value store with some ability to emulate relational stores. But pointing out that people who do not need the USP of Cassandra, massive scalability, will not use a 'product' that is only on version 0.8 when they don't need its USP and they can use a number of other open source databases to do what they want and not care about scalability is a total non-story both for the research and for this article.

2
0
Stop

Re: SQL or relational?

>"Are you talking about the relational DB model or SQL, as in the language?"

Neither. The article is talking about NoSQL, which is an approach that has never had anything to do with SQL versus any other means of expressing a database query, nor indeed anything to do with relational versus any other means of structuring a database, but has always been a euphemism for simplistically throwing away ACID properties in pursuit of misleading measurements of raw access speed (that neglect to count in all the extra work you have to do if you don't have ACID).

It was a simplistic bit of vacuous marketing sloganeering from the word go and never anything more than that.

7
3
Silver badge
Stop

Sorry I have to disagree

If you read the original article, the author talks about SQL vs NoSQL when the debate is actually about relational vs non-relational. He misunderstands the terminology.

Unfortunately, the NoSQL term misses the point entirely about what the NoSQL "movement" is all about which is dispelling the long-standing IT dogma that the relational model is the best solution for all storage/retrieval problems when it plainly isn't. Hierarchical data is one of a number of examples that do not fit the relational model at all.

Sadly, a few commentators on the subject have not really looked at the landscape to see what is really going on. There is much research and experimentation going on which is only a good thing for evolution in this area, a field which has stagnated a great deal in the last 20 years.

No-one is talking about throwing the relational model away. In many business situations an RDBMS is the proper and ideal solution. But for many applications, like search engines, large scale analysis and social networking sites, for example, the relational model is hopelessly inadequate.

0
0
Meh

I keep seeing people remapping their ORM onto these tools too

I generally work with Rails and we did do some stuff with Mongo (before we threw it out and did a warehouse - which is SQL but deffo not relational IMHO).

The thing that annoyed me was someone wrote an adaptor that worked fine with the tool and gave you some useful abstractions that modelled the way it actually *worked* - then some other dimwit came along and tried to make it look like Active Record - then the developers tried to use it like it *is* active record.

It fell into a world of pain - it works differently, it has a different use case, it uses map/reduce. Don't try and make it look like something with SQL underneath it - use it how it was intended an you will get what you need. A list of key/value pairs you can get to quickly from a key, or a large set of relatively homogenous data you can ask questions of. SQL-type joins just eat resources because you *always* have to do the equivalent of a full table scans to join your reduced sets together. We kept using up all of the memory on our Mongo instance once it got past a certain size.

Pick the right use case, this stuff is brilliant. But the number of use cases compared with SQL is really tiny.

Pedantically, SQL doesn't do a good chunk of the relational model, it's a pragmatic attempt at something that did the bits that were easiest to implement (in the 1980's). A system that implemented a true relational model (as in tuples that contain whole rows, for example) would do everything these systems do and SQL can do. Have a trawl around the O'Reilly catalogue for some of Chris Date's newer work.

I've no idea how to implement this though. But the theory is really sound and complete.

0
0
Coat

Terminology

ACID is a quality of database management systems. Those that do not support it are not database management systems - period. ACID has nothing to do with the underlying storage mechanism or logical design philisophy (heirachical, network, relational, object etc.) of the database management system.

SQL is a query language, one of many, and is a mechanism for interacting with data stored in relational databases. SQL has many flaws (the subject of several books), however these flaws are not flaws with the relational model per se. Conflating "SQL" to "Relational Model" is what ignorant journalists do, and having made this invalid conflation, they begin to utter drivel about the "next big thing", failing to recognise that their conclusions are based on a bkoken premise.

The TABLE structure of relational databases (a logical thing) does not preclude extremely sophisticated very large large databases with data physically structured and distributed to meet the size, business and performance requirements of a business. Phyisical implementation of logical data structure has absolutely nothing to do with SQL or the relational model. They are separate things, as even a casual glance at the CREATE TABLE syntax of any sophisticated relational database clearly demonstrates. Sophisticated database management systems running on sophisticated OSs have sophisticated physical storage capabilities.

I have no real clue what NoSQL is (nor am I ever likely to care). It is irrelevant and loved by people incapable of the intellectual rigour necessary to do data design, and journalists needing some copy.

Dweeb

5
0

But ... MongoDb is web scale!

An amusing take on MySQL versus MongoDB:

http://www.youtube.com/watch?v=b2F-DItXtZs

(Some language in the clip is NSFW.)

0
0

NoSQL has its place

My current position requires SQL. It involves pharmaceutical data, and trust me, if your health is in the hands of an EMT, you want a proper database behind the data that EMT is using. I've also worked at research facilities and at places where data was amalgamated from different sources, and I can see the benefit of NoSQL here because the data really doesn't fit into a set pattern that a proper RDBMS provides.

But remember, business is a great American institution, and like all great American institutions (baseball, blues, muscle cars), it is essentially conservative. A great example was when IndyCar announced the new car for 2012, they stayed with Dallara for the car's chassis, partly because "we know the crash data". That is no small consideration for someone hitting a wall at over 200 MPH. Likewise, we know the crash data for Oracle and MySQL; we're still gathering it for NoSQL. So businesses will let let that crash data come in before they look into investing all the time and money into a NoSQL conversion

0
0
Devil

Follow the money?

I have been told that Microsoft system administrators make less than Unix system administrators, hence business' dislike for Unix.

The hypothesis does explain why Unix administration still looks like we're in the seventies. Problem is, people do forget it is about job preservation and think it is a really good idea.

0
0
Coat

Couldn't agree more @Dweeb

Most of those championing NoSQL simply have missed the point when it comes to RDBMS.

I'm constantly amazed at the lazy, crappy applications that loop over SQL tables retrieving records one at a time (Java programmers I'm looking at you) and then have the temerity to complain that

a) Their app server doesn't have enough memory (16gb for a few tens of users!!!!!) or

b) SQL is too slow for their app (it can cope beautifully with tens of millions of rows a second on 4Gb of Ram)

Most commercial off the shelf enterprise apps are guilty of this. Most of them haven't even heard of a stored proc, primary/foreign keys or even the Update statement. A five year old could write more efficient code.

Go back to using Excel you useless lazy, ignorant tossers

6
0

If you think Java database apps are bad ...

... you've clearly never seen the havoc that Ruby on Rails can cause.

I recently witnessed a Rails application bring an Oracle database server to its knees because it wasn't using bind variables. Instead, the Rails app hammered the server with millions of explicit SQL queries that were identical except for the value of the column in the where clause. It pretty much killed the Oracle query cache.

The DBAs still grimace in pain when Rails is mentioned.

1
0

The wise analyst

I thought that I didn't use NoSQL solutions because none of my customers had requirements where the advantages of a NoSQL approach outweighed the disadvantages. Thanks to Steven O'Grady, I now realize that it's just because I'm dumb as a box full of rocks.

1
0
Megaphone

not just growed-up stuff...

Was this an epiphany?

"This is what the open-source crowd missed for years, myself included, as we raged...."

Opening this up a tad, explains why loonix has died on desktop, netbook.

I have no tech expertise but keep a really small boring loonix user network running.

It took me two days to find how to relax users read-write permissions so that group members could share files on a new install. It's changed [unannounced again] and buried [as usual] and I'll never remember where it is.

I sure as shit couldn’t click on a button to did that..

Every loonix consumer & semi-serious install should be as easy to use as Android, meego...

Oh God how I wish that were true and Oh God do I know that will NEVER happen..

1
2

lowering the skills bar

>by relentlessly lowering the skills bar for application developers and IT administrators.

More from the perspective of a user... not as a developer.

I just want something that is easy to understand, modify and find help when I need it.

I started out using the technically superior unix/unidata.

Once I had developed a few skills, I felt superior too.

Since then, I've dealt with a few other languages and systems.

I'm surprised how little progress has been made & how much they all seem the same.

So, now I like to stick with the established, lowest common denominators.

I REALLY have to be motivated to invest in new tech.

0
0
Thumb Down

Also in the news...

...bears shit in the woods.

Has it occurred to anyone that massive denormalized data retrieval systems are, y'know, fundamentally incompatible with the needs of storing normalized, granular data?

If you apply NoSQL methodology to business needs, you get a slow, clunky, inefficient, corrupt mess, just as you get when you apply monkeys to sorting your filing cabinets.

0
0

Page:

This topic is closed for new posts.