Just one tiny mistake in the article:
Mysql IS NOT ACID compliant, even if someone @ mysql ticked the feature. Triggers / fkey interaction is not acid compliant in every single case.
This is akin to the much lesser issue of mssql accepting a trigger chain of max 32 depth, thus breaking ACID beyond that level (a detail, but important to know).
The only problem that is mentioned in that article is that venture capitalists are re-discovering that return rates do not scale.
Not very surprising.. most of the return VC's make are from acquisitions or IPOs, and you can hardly imagine Oracle or Dell buying one zillion companies every year, just as you can hardly imagine everyone entering the IPO's of a thousand companies every year.
The more startups you have, the less news about each of them, the less chances of success as well.
The better the ROI, the faster you hit the wall of decreasing returns.
The main reason returns are down is that there is probably at the very least 10x more money in the VC industry than 8 years ago (1 +3 due to returns, +6 due to way more people interested).
At some point you have to wake the fuck up and realize that 12% annual over the course of a hundred years equals x83, something that cannot possibly scale, much less for another hundred years after that.
That much money means that VC's are chasing entrepreneurs trying to give them money, even when their ideas are completely dumb (memSQL for one), maximizing total profit across their investments, but decreasing profit rate due to lower quality opportunities (where they would've funded the top 1%, they now fund the top 10% for example).
Another web2.0 company with absolutely zero understanding of databases ? IMPOSSIBRU !
EAV is the half-assed approach to data management. When in fact it would be just as easy to store the information in a newly created table, some people consider it's way too hard (lol) to do dynamically and thus prefer EAV.
And then some of those fools go as far as to say that it's better for keeping track of row versions (which is retarded, because ... just write the query to return the state of a group of objects at a set date and you'll understand) and whatever.
The correct approach : read data to array, create_table(array), just run a select to get a row.
The EAV approach : read data to array, break it up in cell-sized chunks, put it all in a table, use retarded long complex queries to do something simple.
Apart from bad OO design or lack of understanding of databases, I don't see what could justify that kind of approach.
This is indeed scary.
Engineered addiction.
Soon to be, automated management of customer addiction.
A few more years and some people will be unpluggable -
Imagine Diablo3:Inferno, except it raises the bar if it sees you're a good player, lowers it if you're getting a bit too hammered, increases the magic find rate when you look a bit distracted (mouse click and key hits density can give you that information, if you exclude chat commands) or keeps the good drops in stock to release them just before you stop playing, so you go on for another hour to check that stuff out.
Sure thing is, the next generation will have even more addiction to fight.
For example, let's say you start with mysql.
You have no features whatsoever, implement your own workarounds or simplified model, create your own text search because there is none (except in Myisam but then that's totally fucked up), and then you migrate to postgres, where every feature is available and working as advertised, you still have your workarounds and text search to remove, and your data model is all wrong because it was made on a pitiful dbms.
MongoDB is the same but worse, it has even less features than MySQL and is not even particularly fast so ...
Those who believe it's slow to design a database are just not DBAs and should leave it to the pros.
I write data models for full applications in SQL directly without any document or plan or layout, and it doesn't take long.
But then, I know why mysql is a piece of crap, I have truly kick ass instead of triggers on views on information_schema that maintain historifying triggers on any table whatsoever, so not exactly a first-timer.
Really, those people are only afraid of learning (the real powerful tools), and will stick to the shittiest ones provided they're just a bit easier to learn.
When google does not use an SQL database, it's because for the very simple task at hand, a full-fledged DBMS is overkill. Because what they do is indexed search. not run a database. thinking you can replace a database with indexed search is going back to the dark ages before databases were invented.
This article says in many words what can be said in one sentence:
Make tech for low-skilled rather than high-skilled kind, there are far more people of the first kind.
That's how mysql succeded, that's how PHP succeded, that's how java succeded, that's how mongoDB and node.js are succeding.
You want your tech to be used widely ? engineer it to fit perfectly in the hand of unskilled individuals.
This is utterly disgusting, there are less good programmers today than there were 30 years ago, and most of that is purely related to the emergence of the "tools for the average dude" that end up plaguing even those who could've learned and become great.
Eat your javascript-mvc-cake . code crap . be happy .
This.
All social networks right now have the same problem, they don't know how to make money without scaring the user away.
They all have far too much advertisement / costs.
They all are afraid of becoming an app, which they are by design, due to providing only one service (a portal works by providing access to all services, it's the game facebook tries to get into).
I, for one, am looking forward to the solution to the advertisement crisis, to what's after "annoying your clients to make a few cents".
Well I'm sorry John, but Java was already a step down from C, and JS is truly paving the way to more ignorant programmers coding random crap with truly no idea of what a processor is or does.
I thought we had enough of those - really. And no, javascript is not the language of the future, and the only reason it got so much attention is because it was the logical first step for web designers learning to code.
Incidently, those same web designers then go on to use PHP, which everyone looks down upon, and MySQL, which I confirm is a true joke of an RDBMS.
I personally wouldn't ever trust anything that fails to deliver in three years, however I'm excessively impatient.
As all the talkers put it, a startup is about being extremely dedicated (and resourceful and stuff, but hey...) and your partner is not.
If he was, he wouldn't have an FT job three years later.
If he was, he wouldn't have accepted the relocation.
If he was, the target market would not change because he's moving.
The first half of the solution is to ignore fads, such as node.js (how could anyone even half-competent use something as slow and fucked up as javascript for their server...)
or mongodb (seriously, who'd compare that to a real dbms like pg or orcl ? )
or ruby (too bad but it's still a decade away from reaching "crappy-but-acceptable" speed).
Why do you people find it necessary to comment on stuff you do not understand at all ?
This is 2012, it would take me about 1 day to provide you with a working twitter viewer that is 100% cachable and for which all tweets are cachable too. All that requires is a one page app for the viewer, and ajax calls for tweets to view like api/tweets/978486971987169876 which will be cachable for everyone.
Content size matters a whole lot because it linearly dictates the size of your server pool. Serving a million small udp packets is pretty standard for any quake server. Serving a million youtube videos is another story.
If only the people giving advice knew what they were doing ...
- php's filter functions : useless, you'll end up cooking up some regex anyway ( be it manual or metadata based)
- pdo ? why ? native drivers can be just fine
- binding parameters instead of sanitizing ? want another hammer maybe ? everything looks like a nail to you obviously.
- password hashing. why should it take place in php specifically when it's one of the slowest layers - and when you could ask the dbms to do it - it's a design choice but are you making the right one ?
Once again . don't call it "the right way" if you don't know the right way, mkay.
Well you guess wrong, Apple doesn't get much stuff made for them specifically, far less in the PC segment.
I.E. they mostly use standard components, and that would be why they have a combo chip instead of the right stuff, as in many cases.
Their SSDs are overclocked mSATA where they should be pcie, and there are many more stupid design decisions or just ease of production compromises that I won't even take the time to look at the black pcb to find out.
Main thing is, most companies have suboptimal PCBs, and that doesn't matter much.