Slashdot Mirror
Slimmed Down MySQL Offshoot Drizzle is Built For the Web
Incon writes "Builder AU reports that Brian Aker, MySQL's director of architecture, has unveiled Drizzle, a database project aimed at powering websites with massive concurrency as well as trimming superfluous functionality from MySQL. Drizzle will have a micro-kernel architecture with code being removed from the Drizzle core and moved through interfaces into modules. Aker has already selected particular functionality for removal: modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists and some data types."
Back to a glorified (but uber-fast) filesystem it looks like.
This is stupid. Removing prepared statements and access control lists? Don't we have enough trouble with people writing insecure web apps when we provide them with the tools easily make them secure?
Fo' shizzle!
A post a day keeps productivity at bay.
I can't imagine what logical reason there is for removing views, unless queries are removed too. Then I'd see where he's really going with this.
And removing stored procedures seems to be more accomidating to the way developers actually write rather than the way they should. Just think how great it will be when all of the processing on every web page is done by php rather than in the database!
Whale
One man's "superfluous" is another man's key feature. No views? No prepared statements? Holy carp. Isn't MySQL crippled enough as it is?
At first glance it's hard for me to see where Drizzle would fit where SQLite doesn't.
Why would anyone in their right mind set up a Web/SQL platform using MS products?
My name is Maximus Decimus^W^WBill Gates, ex-commander of the Armies of Redmond, General of the MS Legions, loyal servant to the true emperor, Steve Ballmer. Father of a murdered operating system. Husband of a bloated Office Productivity Suite. I shall have my vengeance, in this web or the next.
Caesar si viveret, ad remum dareris.
...reinvented, but with security flaws. Awesome!
Uh, doesn't removing the query cache run counter to the goals of making it fast?
It just begs the question, Who is the Drizzle?
"He may look like an idiot, and talk like an idiot, but don't let that fool you. He really is an idiot." - Duck Soup
Would this be a candidate for a light DB server for a mobile device? Perhaps for address books, media catalogs, etc... Could it find a niche beyond the web? BTW, IOANADBE (I obviously am not a database expert). IAANAAE (I am also not an acronym expert)
One ring to bind them - should probably have more fiber and less rings in their diet.
So this is basically a client/server version of sqlite with better concurrency, minus a bunch of useful features like views?
LADP? DALP? PADL? (Up shit creek without, presumably...)
Why "Drizzle"? What a damp, depressing, generally wet name....
Find Japanese addresses in English on Google Maps Japan: http://diddlefinger.com/
I always thought SQLite did a perfect job of filling in the space between the need for a full blown database and the weight it adds to the server setup. SQLite, as its name suggests, is very lightweight. Where exactly will Drizzle fit in?
Is this just a stripped down MySQL? Or is it a fork that actually bring some interesting new scalability features to the table that are otherwise unimplementable in the current MySQL architecture?
Maybe it's my pre-caffeine morning stupor, but the site seems void of any real details.
For shizzle?
...perhaps I should considering using a database on my website. MySQL always was too fat.
FUCK SLASHDOT!
Throw out Triggers???
Junk-in and Junk-out with bloat code on top trying to validate and synchronize very thing.
I guess it the '70s all over again.
Finally, with even views removed, MySQL can move toward its original dream of having *no* features at all -- *no* separation of interface from implementation, *no* referential integrity, *no* bundling of logic with data to ensure data integrity, *no nothing*!
After a period in the wilderness, during which versions 4 and 5 added hated so-called 'features' and 'functionality', we are now finally returning home.
I look forward to Drizzle version 2 in which pesky 'tables', 'columns' and most of all the fancy and pointless 'select' statement are removed.
Seriously, no *views*?
So, what we actually have here is a thin wrapper around InnoDB. If Sun have turned MySQL primarily into a quick-start wrapper for their own product, that's actually pretty clever.
Whence? Hence. Whither? Thither.
How is "massive concurrency" and the lack of these features compatible?
What I want is massive concurrency in a full scale, disk based, highly available, highly scalable cluster. Can we get that right, please?
It's the lack of Windows support that *particularly* suggests that this is all Sun's strategy for spreading InnoDB... ...with a couple of MySQL devs along for the ride either because they have no choice or because Sun stroked their egos.
Clever Sun. Now all they need is a server platform :D
Whence? Hence. Whither? Thither.
By slimmed down it means they've taken tranasactions and all the referential integrity checks out?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
You shnizzle dude, wizzle on my dizzle, like totally gansta. I is gunna pop a cap up your arse.
Hey, I'm English and this is how all Americans talk on the telly ;-)
Proof that when MySQL originally added those materials, they still didn't know why they were important. Some of these aren't even going to slow you down much. Prepared statements can speed you up in some cases.
In this state, it occupies a spot that SQLite does just fine.
Not a typewriter
This is something which can only further promote bad programming practices.
But then I'd never use MySQL anyway.
I have been developing for the web during the past years and that's why MySQL has been off my list for serious development for some time in favor of Postgresql. It took about a decade to implement basic features like views and foreign keys that even Access 2.0 had in 93. Even sqlite has views for god sake!
Today, even for the most simple projects I cannot think about not using views, stored procedures, and triggers. Not because there is no way to do the job, but because they are important for organization, security, data integrity, etc.
It is like they have no idea that web sites are getting more complicated, and more and more data is involved everyday. I can't think of someone creating a big website with massive concurrency using this. Sounds more like an alternative to Sqlite for very simple tasks.
Why would anyone in their right mind set up a Web/SQL platform using MS products?
You'd be surprised. Our web team recently got on an "I love MS!" kick for some reason. They'd been on Linux for years but a lot of the new/shinny buzzword stuff that they wished to install wanted Active Directory, IIS, and other non-sense. Because the Linux setup didn't lend itself well to installing all that proprietary stuff, and because they convinced themselves (somehow) that the most popular software is always the most insecure anyways (so Apache being the most popular webserver is the most insecure), they switched to Windows + IIS (+MySQL, but SQL Server is being pushed hard) to host the website.
Now I've even had pressure to convert my servers from Linux to Windows where possible to "standardize".
On a more on-topic note though, I'm not sure where this leaves MySQL itself. As a "real" database, it naturally can't compare to SQL Server or Oracle, but even competing in the free segment, PostgreSQL blows it away. Traditionally MySQL was just the toy database for non-critical stuff that you wanted speed out of (and little else). If Drizzle accomplishes that, then I don't see a real place for the mainline MySQL anymore. Drizzle if you want speed, PostgreSQL if you want features/stability, and Oracle if you gots money to spend.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Why would anyone in their right mind set up a Web/SQL platform using MS products?
Because it is reliable, easy to develop, implement and support?
Now if we could just get a hiearchical data model and associated standards based query language at the same time (XML, xquery, xupdate, etc) it truly would be Christmas come early. The potential of a FOSS, production ready NXDB is intoxicating (Exist-db, Monet, etc. are sooo close).
That's people writing triggers on every damn table!
I think "Vapor" would have been a better name. This is even lighter than SQLite which incidently does have views, triggers and prepared statements. I really fail to see the point or the market, unless they are aiming at the embedded sector... but the article says "powering websites".. FAIL!
Why not just use PostgreSQL and get away from the MySQL mess entirely?
... in a server meant for high concurrency use ... isn't that just shooting yourself in the foot or what?
---
"The chances of a demonic possession spreading are remote -- relax."
So basically they are going to re-release MySQL 3 under a new name.
Hooray for Launchpad!
Colin Dean Go a year without DRM
Dude, I want what you are smoking!
Seriously? Windows? Reliable? Easy to develop for(Nothing without a decent command line is "easy to develop for in my book) for? Easy to implement? Windows management tools are a joke compared to mac, and Linux has tons of really good tools that kick the crap out of the amalgam of XP tools that are functionally useless, confusing as hell, and ugly as sin to boot. Easy to support? Have you ever tried to repair a registry? Not fun.
Monstar L
If you're going to pull out all the functionality, why not just use sqlite? I personally use an InnoDB setup so I can use Drupal's "related content" module so I won't be switching, but the next drupal is reputed to use sqlite as a backend and if I weren't using this feature I'd go to that. Simpler, lighter. Always present with PHP5.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I normally develop on a WAMP stack (WAMP = Windows + Apache + MySQL + PHP) specially built for developers that can be set up very quickly through an installer. After the site is done I can move it almost seamlessly to a LAMP stack. I also have a VMWare with Ubuntu set up for any cases in which I need an actual LAMP... but I hardly ever need it... which is good, since it hogs much more resources (quite a chunk of RAM) and is slower to boot up. So... Drizzle not being supported under windows sucks.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.
The thing is, is that not everybody needs a full ACID compliant transactional database. All that stuff tends to slow down the whole database. It would be much nicer for many people to just have a simple non-transactional database. Think about how many web apps are out there that don't use transactions, and have not need for them. Many applications would benefit from increased speed over increased transactional capabilities.
On another note, what's with the lack of hosting services providing PostgreSQL? I would love to use it, at least for some projects, but the fact that it's not available on many hosts makes it quite a hard decision to make. I don't want to pick up another hosting provider, or switch over all my stuff just to use a different database.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Get on board MS! Why would anyone in their right mind set up a Web/SQL platform using MS products?
Because, despite your prejudice, there is a business case for it. And business wins over OS zealotry. Besides, it is open source. Someone who is able to exercise common sense will simply port it to Windows.
And stop telling me what platform I should use for my apps, darn it! I don't see your time and money here in front of me doing the work, so stfu and just give me the tools that will get the job done.
OS Zealots are worse than spammers.
Bearded Dragon
Seriously, when I saw that views were likely to be cut I was going to ignore this product. But a line like that gets me onboard.
Nobody ever got fired for buying Microsoft, but that's only 'cause I don't make hiring decisions. Yet.
My turnips listen for the soft cry of your love
Yep - it sounds like the Assembly Language version of a DB, built for massive speed but requiring very careful programming to avoid crashes.
Sometimes that's just what you need. Sometimes it's exactly the worst possible approach.
I say let the problem requirements decide which to use.
I used something like this back in the late '90s. It was called "MySQL 3" and made by a Swedish company named "TcX AB."
What is old is new again.
From my point of view, this is MySQL finally embracing their target market.
These features are great and important, but if you're doing small scale web programming through a framework that uses an ORM, or just very simple SQL, why not slim the program down?
If you want real database features, you probably shouldn't be using MySQL in the first place in my opinion.
Blessed are the pessimists, for they have made backups.
This shows a big problem.
Most people don't understand rational databases. As most colleges CS programs don't even touch SQL except for perhaps as an elective. There is a huge knowledge and a lot of miss use of SQL. They treat JOINs and Views as advanced features while they are actually still very quite basic features. Because of this a lot of people use SQL as a replacement for reading a flat file poorly designed with duplicated data, no indexing etc... etc... etc...
These features that seem to make it seem slow actually improve speed, for a lot of cases. eg. a View that takes 1 second to load could take 2 seconds total for the application to select 5 or 6 different tables then try to use logic to put the information together as the application say php or python are a higher level language then a C/c++ written database server. Also there is the additional coding time as it is much easier to reuse or extend on views then to modify code. So yes using a complex view or stored procedure will slow down the database server however if it doesn't slow down the database server it will often end up slowing down the web server instead. being the Web Server is end user facing its speed espectially for usually fast to load simple pages that are use most often are more important then waiting the little extra time for the database to get back from your complex or large request.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
These people want to remove prepared statements and stored procedures? When they are probably one of the best ways to prevent sql injection??
I think the invisible hand of the market has its middle finger extended
--A wise old fart named SC0RN
Because it is reliable, easy to develop, implement and support?
Neah, that can't be it.
I hope the database will run on Zune so I can squirt my Drizzle.
Traditionally MySQL was just the toy database for non-critical stuff that you wanted speed out of (and little else). If Drizzle accomplishes that, then I don't see a real place for the mainline MySQL anymore. Drizzle if you want speed, PostgreSQL if you want features/stability, and Oracle if you gots money to spend.
The thing that people always seem to discount when comparing MySQL to PostgreSQL is community mindshare and comfort level. That's why it's called a LAMP stack. If products always won on technical merits, 90% of PCs would run OS/2 instead of Windows.
I'll admit, even though I "know" that PG is supposed to be a better database, anytime I'm starting a new web app I go for MySQL. It's what most of the frameworks and toolkits support first and/or best. It's what more tech support guys at the web hosting companies are familiar with. Plus MySQL has *much* better GUI tools than PG.
If both products were starting from scratch, then yeah maybe PG would have a good shot. But MySQL isn't bad enough, and PG isn't better enough, to make me or others like me feel like switching. I'm not comfortable with the PG toolset because I'm not familiar with it, and I have better things to do with my time than learn it, because for me the perceived potential benefit isn't worth it.
Of course, none of this is to say that Sun won't f*ck up MySQL enough to make me change my mind...
Yep. The reason for Windows support in open source software is so that, come hardware crunch time, you can easily slide the OS out from underneath and triple the performance and look like a star. All OSS must support Windows purely so sysadmins can pull this trick.
http://rocknerd.co.uk
Sounds like you are trying to spread FUD. I'm a Linux guy but I'm also a Mac guy and Windows guy. I use them all. In my 8 years of running Windows in a medium organization...I've never "repaired the registry." I also find Active Directory and Group Policy to be fantastic. You can install cygwin to get your proper shell fix but even PowerShell isn't all bad compared to command/cmd. I also find our handful of Windows Server 2003 boxes to be reliable.
As for development, I prefer to develop on Linux for Linux but it's really whatever you're comfortable with.
Seems like everyone is missing the point that the features aren't being completely removed, they're just being removed from the core and separated into modules.
That's because most of these people are writing their applications to be cross-platform applications, or at least with the intention of them being cross-platform at some point without re-writing the whole thing. If you don't know that you're going to be hitting against a DMBS that provides true ACID compliance and that has powerful stored procedures, it's probably a good idea not to depend on those features for critical functionality.
Also, you're forgetting who most of the databases we're talking about are aimed at: hobby or small-scale web developers. If you're writing something like Joomla! or phpBB or MediaWiki or whatever, it's pretty safe to assume that the people who are using your software won't have access rights to create things like powerful stored procedures (that, if written poorly, can <censored> up everyone using that database) even if they are supported by your DBMS. Such is the nature of $4.99 a month hosting plans; you typically don't get much more than INSERT and DELETE and SELECT.
Frankly, MySQL is a lot greater than what 99% of users use it for. Drizzle is targeted at 80% or so of those 99% to provide an even faster and better back-end. If your application is such that it needs features that aren't supported by Drizzle or even MySQL, by all means, use whatever it is you need. But really, I don't see much use in basically telling people, "You're not using it right!" when it does exactly what they want it to.
If both products were starting from scratch, then yeah maybe PG would have a good shot. But MySQL isn't bad enough, and PG isn't better enough, to make me or others like me feel like switching.
And that's the problem. Because people don't try it, you don't realize how much better PostgreSQL really is. It really is more "better enough". ;) Until you give it an honest try, you really don't realize what you're missing out on.
Because, despite your prejudice, there is a business case for it.
I think the GP is suggesting that there is rarely or never a business case or using Windows. I am not saying he is right, but that his argument need not be interpreted as zealotry.
Incidentally, Ackers presumably thinks that there is no business case for supporting Drizzle on Windows. Not supporting one platform should lead to cheaper, faster or better development.
all I know is it's not Master Shake, although they are very close friends!
It's also proof that the creators never did understand views, stored procedures, referential integrity, triggers, ACID database properties and everything else that makes a true relational database like PostGreSQL.
Really? I thought LAMP was a marketing buzzword for selling O'Reilly books.
It's a very dark ride.
Sorry, it is incomprehensible that this sort of project would be started.
The problem with MySQL, to BEGIN WITH, is that it doesn't support enough SQL or the SQL it does support well enough, to construct efficient queries. What ends up happening is that you move your "data logic" to your application and out of your database. This means the database handles simpler queries, but returns more data. While these simple queries appear faster, they hit more data on the disk and actually cause the system to become I/O bound.
"Real" databases handle the "data logic" close to the data and can estimate the most efficient access to the data needed, thus REDUCING the I/O bottleneck, making more complex queries more efficient than simple queries. CPU time is virtually free with respect to data access.
Every time I see some Java, PHP, or .NET guy go off about MySQL being faster, I just shake my head. Data access is a real science grounded in math and the physical realities of actual computers and storage devices. A "good" database has YEARS of research and unless you are a god (and you are not) it will be very hard for you to beat it.
I've been in the business for about 28 years and I don't understand why software developers have this blind spot about databases. Maybe it is a "not written by me" attitude, but I just don't get it. A "good" database has so many facilities to make your data access efficient and fast as hell. Yet, most developers that I have to direct, simply refuse to learn about databases, specifically SQL. They go out of their way to write elaborate functionality in their language of choice that could have been constructed in a moderately interesting SQL query, that could be wrapped in a function and been more efficient.
The "drizzle" product is just another avoidance of an important semester of computer science that people don't want to understand and will ultimately create even more poorly designed web sites.
Really tiring... really... Still C++... should require C compiler complexity only ... well, should go for GIT instead.
Bazare is
And GPL for what, since we have to surrender our GPL rights to a for-profit organisation(Sun upper management and board) and in no case I would like to have my code in their closed proprietary forks...
We need a Linux-spirit-like SQL DB engine for God Sake!
I know you said you don't want to switch, but:
Lunarpages kicks ass.
Not an employee, just a long-time, satisfied customer.
I foresee many posts on thedailywtf about projects which implement this 'technology'...
If you don't like the feature set use the regular MySQL. This isn't meant to replace a general database, it's an architectural trade-off to solve a very specific high concurrency issue by optimizing both feature set, design, and code. If you don't like it or think you know better don't use it. Good Lord, they didn't take away your precious, just offered you another option.
and what the hell is the obsession with a "slimmed down" database for web apps? it's not like the client is downloading the database backend. make the database backend as feature full as you can to make your apps, you know, BETTER.
my prediction is dribble will be used by a few nob headed php programmers, who will shortly post on /. how the dribble database is 10x faster than regular mysql. they will also forget to mention that it fails at anymore more complex than select *
If you mod me down, I will become more powerful than you can imagine....
Master Shake: Drizzle here. ..have put Fat Albert in a can. ...Have put Fat Albert in a can..in your can.
Meatwad: Yes, Drizzle? Violent criminals have put.. what did you..Fat Albert?
Frylock: Prince Albert..
Meatwad:
Frylock: No, no. It's Prince. Prince Albert.
Meatwad: Oh, okay. Hang on.
Master Shake: I'll need precise coordinates, ma'am.
Unless you need partitioning support.
a handful of selfish greedy people are no match for millions of selfish, greedy people -u4ya
I'm guessing you're going for a "+5 Funny" here, right?
The wiki says there is no FULLTEXT support. TFA says no Prepared statements and no query cache. How is this supposed to be good for a web application?
Check out my cross-platform apps
Why would anyone in their right mind set up a Web/SQL platform using MS products?
Because you always use the best tool for the task at hand? And there are many situations where IIS and MS-SQL do a damn fine job.
To blindly use one OS or app just shows a lack of dicipline on the developer.
Can you expand on what you mean? Some databases have a more expanded view of what partitioning means but PostgreSQL does support partitioning.
windows servers are very reliable, netcraft confirms it http://uptime.netcraft.com/up/today/top.avg.html. in fact linux isn't even in the top 50. put THAT in your pipe and smoke it
windows is also by far the easiest platform to develop for. .net is a brillant product, sql server is also brillant to use and compared to oracle it's cheap as chips. it also comes with tools like reporting services which OSS simply has no answer to.
i've developed under BSD and windows for years, and windows has by far had better tools for the last 3 years. i just get the feeling you don't know what your talking about....
If you mod me down, I will become more powerful than you can imagine....
Could you share some 'buzzwords' with us that require Active Directory, IIS, and other nonsense?
It sounds to me like you had a bunch of Windows developers forced to use linux who didn't 'get' it and switched to Windows ASAP. But that's just a guess.
I switched jobs and got stuck into an IIS+Windows+MSQL environment, and I've been truly stunned by how bad these tools are for web development.
At least I've still got PHP, even though the Windows developer I'm stuck with thinks it's C and insists on hard-coding enums and shit like that, instead of letting us take advantage of loose typing and database-driven development...
hahaha ZING!!!
I used to do the same thing, reach for MySQL for web applications first simply because there are more hosting companies supporting MySQL for a large number of reasons. I reached for PostgreSQL for intranet or business application where clients could use the features, but maybe could not afford or wanted to spend the money on SQL Server or Oracle. But in the last couple years, I've noticed more hosting companies offering PG support as well. However this changed for me in the past six months when SUN purchased MySQL.
But SUN buying MySQL and then not really having any what I would call "firm plans" on what they were going to do with it was enough for me to look at PostgreSQL as the db of choice for the latest application I was hired to develop. At this point, PG development seems to be more of a known quantity.
I could be wrong and Sun might create something that is absolutely amazing and the best. thing. ever. But until then, I'll stick with what I know till something better comes along.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
I use MySQL and PostgreSQL every day and whenever I have a choice, and if it makes sense for the project, I reach for Postgres. MySQL may have better GUI tools and I'm sure that's important for some people, but PostgreSQL just works more like I want / need a database to work. For the kind of work I do (non trivial queries with a significant degree of write operations), it's as fast or faster than MySQL in any area that matters. If you don't see any perceived benefit to using a more robust, more compatible SQL implementation, then you probably aren't using a lot of what most RDBMS systems have to offer. And that's fine! There are plenty of places where people are using a database as a glorified storage box for object persistence where any fancy SQL stuff is almost a waste and that's a place where something like Drizzle makes a lot of sense.
Woosh?
Actually, Windows + Apache + MySQL doesn't make a bad server. That's partially MS. I set one up for someone in my family also, and it's worked great for him. I'd rather have used FreeBSD, mostly for easy remote administration, but aside from the remote admin issues, this setup has worked very well.
With a decent firewall, and keeping the system updated, Windows isn't a bad server operating system at all. The software you use on it may change the quality, but you can fix that by using good software.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
Linux not being in the uptime listings is not because all those Linux machines are crashing, but because of the method used in Linux to measure uptime. In fact, NetCraft even has a FAQ on this here. It's pretty much common knowledge at this point that Linux servers have better uptimes than Windows servers, and that BSD rules the roost (and that absolutely every VAX machine that ever booted VMS is still running!).
.Net is brilliant, and really makes complicated programming accessible to idiots (you can argue about whether this is a good thing or not!). For me, it comes down to "do I spend the cash on keeping Windows Server licenses up to date, keeping SQL server licenses, keeping techs paid to do the routine Windows maintenance, etc, but get away with hiring a cheaper, less skilled programmer" or "do I lay out more cash on a better programmer who can handle developing under Linux, but save the costs of licenses, (some) maintenance, etc"? The decision depends on the situation.
That said,
Shake: [Answering phone] Drizzle here.
Meatwad: Hello, yes Drizzle. Violent criminals have put...Fat Albert, what, what it's...
Frylock: No, no, it's Prince Albert.
Meatwad: Oh, have put...Fat Albert in a can, in your can.
Shake: I'll need precise coordinates maam.
Meatwad: Oh okay, it's...it's in your butt, boy! It's in your butt! Did you hear me? It's in your butt.
Shake: Pranksters! Sons of-
But someone still has to write those sorts of triggers, for every database, every time the create one. Why isn't this sort of audit logging (changing, data changing, etc.) built in to the database engine automatically, with a few configuration options available?
Data and table change logging 'by default' would be immensely useful, and if it's done optimally by the db authors, you're going to avoid issues of poorly written useland triggers and stored procedures by people who aren't as intimately familiar with the core engine.
creation science book
It's probably the fact that cPanel's support for postgres sucks, it only supports 7.4 and getting it to work right is a pain. Plesk is a bit better but you have to pay for extra licensing to use it.
It's hilarious how half the comments here are saying most of the processing should be done client-side for the sake of portability, and half are praising the merits of stored procedures and suchlike in the name of security and performance. If you understand abstraction, it's a painfully trivial matter to write your web app to support either method as the situation demands.
C'mon guys, this is basic first year Comp Sci stuff. You *can* have it both ways.
...but then again, I work with Oracle.
Advice: on VPS providers
There isn't a better command line than PowerShell. If you're really hung up on bash, install SFU.
As for repairing a registry, I've been running Windows clients and servers for >10 years, and I've never needed to. If something did get that broken, I'd just reimage the box, no big deal.
Karma: Poor (Mostly affected by lame karma-joke sigs)
http://www.youtube.com/watch?v=rZ5GXPg_gD8
Assorted points that indicate that you do not know what you're talking about--
-Why are you installing software that could corrupt the registry on your server machines? Sounds like incompetence to me.
-Do you really mean to say that OS X has better server management controls than Windows? Really? Because if you are, I would like to know what mystery world you live in where "bad" became "good."
-Linux does not have anything that approaches ASP.NET in terms of functionality, ease of programming, and feature completeness. Java Server Pages are horrible. Mono (who I do some work for) is only at ASP.NET 2. PHP/Python/Ruby? Please.
-The Windows command line is poor, yes--but if you're working according to the platform's paradigm, that weakness is avoided because you don't use it. Besides, cygwin works fine if you insist on it. (I've started to use PowerShell, which is also quite nice.)
-SQL Server is significantly superior to MySQL, faster than PostgreSQL, and for most businesses is cheaper than Oracle.
The only one smoking anything here is you.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
I think the GP is suggesting that there is rarely or never a business case or using Windows. I am not saying he is right, but that his argument need not be interpreted as zealotry.
Sorry, but saying that there's never a business case for using Windows is zealotry.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
The only time I have the database do the processing is when it's either vastly faster or vastly easier. To put it simply, it's cheap and easy to scale up my webserver farm, and difficult and expensive to scale up my database.
In the real world, developer hours are the most expensive part of most IT projects. You are highly motivated to write code within your comfort zone that will not require heavy maintenance in the future. So yeah, that might mean doing a broad query and doing the sorting/filtering/analysis on the webserver. That puts the heavy lifting in Tomcat/Perl/PHP (and unlike SQL, those languages don't need to have their syntax extensively futzed with when the platform changes because this year's CTO is a Microsoft Fanboy and his predecessor was an Oracle Victim). If the webserver runs slow, fine-- I throw another webserver at it and check the "stateful http session" button on the load-balancer/firewall. Costs me about 5 grand and even gives me other bennies like redundancy. If that saves us a man-week of dev time over the next few years than it's a steal. (Infrastructure load? My boss doesn't care. That's the facilities budget, not IT, and the marginal cost of running one more PE1850 is negligible anyway.)
Oh Hi! I'm a database admin/weirdo/geek and I have "big issues" (TM) with any and all database technology, and related discussion that does not fit with my myopic view of the world! This Drizzle does not make me happy. You kids! GET OFF MY LAWN!
Let me show you an approximation of what this article looks like to some Slashdot posters, in their hurry to be frist pots. . .
"Builder AU reports that MySQL's director of architecture, has unveiled Drizzle, a database project. . .will have . . . code being removed from the Drizzle core. Akers has already selected particular functionality for removal: modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists and some data types."
See, it all makes sense now.
modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, access control lists and some data types
Views: Most commercial grade systems use them to denormalize collections of data for frequent data transformations and easy reporting. In my experience they're not needed on smaller, simpler, or less normalized databases, but on very complex databases they're essential.
Stored procedures: Typically used to push the business rules for pure data manipulation into the server where they can be executed more efficiently. Again, smaller system don't need them, larger systems will scale better with the ability to put the processing where it can be done the quickest.
Query cache: I can't imagine why you'd throw out the execution plans for frequently used queries. This is simply a performance issue, and high concurrency systems will drag without caching.
And so on. And there's no support for a Windows version. In every instance, including the statement from the FAQ, "'This is not a SQL compliant relational...' Very true, and we do not aim to be that," it's obvious this isn't intended to be a commercial grade, common OS, broadly used, SQL compliant database engine. It's a hobby engine. While the author of the article lauds InnoDB, I honestly believe that the mindset is to produce a database engine microkernel, a la Linux, that will result in an organic, evolutionary model of distros, with various versions and feature sets arising with the fittest surviving.
Which just means I'll be using MySQL.
Sorry, but my software is database-agnostic, insofar as it expects SQL-92 compliance. I have no use for an extreme low end, non-scaleable out of the box, handicapped database engine. Why would I? MySQL gives me everything I need for doing any application I can come up with, and with the correct configuration it body-slams its best competitors.
Thanks, but no thanks.
*** *** You're just jealous 'cause the voices talk to me... ***
Better how? I admit I haven't used PG simply because MySQL is what I've always used, and it works perfectly for the tiny projects I tend to futz around with (like my jukebox and website driver etc). I don't use stored procedures, I don't use pretty much any of the "advanced features" like replication, transactions, or pretty much anything that appears to be marked for removal from the Drizzle core. The apps I use are designed to be write rarely, read often, and all I need is good performance on the read, a reasonable relational structure, and the ability to do reasonably complex SQL queries.
So, how, exactly, is PG "much better" than MySQL for me? I've been tempted to switch a number of times, but I never found a reason why it would work better for me.
Argh, I had mod points yesterday, but not today when I needed them! :-(
Yes, views and trigger and stored procedures are good, and if you have a really competent DBA that is part of the development team and can take responsibility for those parts, and if you're ok with being tightly tied to a certain DB, then fine.
But most projects don't look like that, and most projects don't need that. If you want speed, then you want to hit the database as little as possible, and when you do, you want it to do as little as possible. Constraints, views, joins, transactions, all these things add up and you lose performance.
Scaling a database is really, really, hard. Shifting the work to the web server and adding a bunch more web servers is easy.
Ask yourself WHY that is.
It's simple: Hardware is MUCH cheaper today than it ever was before, and it'll be even cheaper tomorrow.
You know what ISN'T cheaper? Software developers.
It makes a lot more sense to optimize for the DEVELOPER than it does to optimize for the machine.
I can add another web server for $5000. Adding a developer is at least an order of magnitude more expensive.
A alimmed down version of MySQL?
Isn't that called Berkeley DB?
Just because it CAN be done, doesn't mean it should!
System administration is where MySQL kills PostgreSQL.
You have to have a DBA for PostgreSQL, you don't for MySQL.
Sanitation is ridiculously easy. You just gotta - like - read your code. Or better yet, let your database driver do the sanitation for you.
INSERT INTO foo (stuff, morestuff) VALUES ($1, $2)
Piece of cake.
Like all pain, suffering is a signal that something isn't right
Without stored procedures, to allow a program (or the programmer who wrote it) access to a given data set, you'd have to grant it SELECT privileges on the table(s) containing that data. With a stored procedure, you just grant it permission to run that procedure, which might only return a subset of the data in the table(s).
Views solve that problem, and are easier to work with as things change over time.
Like all pain, suffering is a signal that something isn't right
The thing is ACID, MVCC transactions are not being removed from Drizzle. Its going to be that way by default. They are just cutting out things like views, triggers, stored procedures and what not. Drizzle is for massively scaled web applications, not a MyIsam based Mysql 3.0 replacement.
Well.. maybe. Or Maybe not. But Definitely not sort of.
For those of us who write sites that need to be able to scale to hundreds of database servers, this is exactly what we want.
When the database is very much behind a firewall on a tightly controlled set of servers, we don't care about access controls. Memcached is a good example of this: no username or password at all. It's not useful on a shared hosting system, but that isn't the goal.
When you're trying to partition your data across multiple database servers, joins, views, and triggers are pretty much useless, since data may very well be on a physically different machine.
When you're trying to do extensive caching (like with memcached) joins, views, triggers, and stored procedures are pretty useless, since you need to do it all client side anyway so you can keep your cache up to date. ORMs make this easier.
When you've got a high write/read ratio (mine is 50/50), query caching is useless.
For those of us writing code that does all the partitioning anyway, we care about speed and data consistency and little else. Everything else is bloat.
There's a reason google released their patches for mysql 4.x instead of 5.0 which was long since used in production.
Imagine this: Apache announces, that it will remove some of its features, like for example mod-php, mod-perl, mod-rewrite.. moved to modules! Gone - forever!
I can live without all the items they've removed, except prepared statements. Without prepared statements most apps will accumulate massive parse-time waits for all their SQL.
What do they gain by removing prepared statements?
Because people don't try it, you don't realize how much better PostgreSQL really is.
If this were really true then a sufficient community of people looking to make it accessible would grow up around it. A common complaint is lack of easy tools to use with PostgreSQL - a reasonable complaint because there is no point in everyone wasting their time using backwards tools.
The fact of the matter is that MySQL does what the vast majority wants it to do, and has better accessibility. Only functionality that is an order of magnitude better is going to overcome that - and while PostgreSQL may be better, it's simply not that much better.
[Ego]out
I have never ran into a problem that Mysql couldn't handle.
Nothing in my post wasn't about "not being able to do something" but that "real databases" are better at it.
Your database elitism just makes you look like an asshole.
I am amazed at the dumbing down of society. Did you know that "elite" means best choice. So my "best choice-ism" makes me look bad?
How about either complimenting the project or just shut the fuck up and don't post? No one really cares what database you think is best.
I offered a valid critique to a project and the basis of it.
Nothing I have written is incorrect or can not be verified. So, rather than insult my "elitism" why not stay "on topic" and discuss the issues.
patent trolls who try to 'drizzle in'....
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Non-hack native partitioning support
a handful of selfish greedy people are no match for millions of selfish, greedy people -u4ya
Plenty of us realize hwat we are missing out on - but the bottom line is, if mysql does the job, using postgres doesn't buy me anything except less staff who can use it and slightly harder to find documentation.
HAHAHAHAHA
It has nothing to do with a DBMS being "crappy" and has everything to do with higher-end features being supported one way on one DBMS, another way on another DBMS, and/or not at all on yet another DBMS, and the real-world situation that some of your customers/users run Oracle, some run MS SQL Server, some run DB2, some run PostgreSQL, some run MySQL, etc.
All of the above examples implement higher-end features differently. Even if two different DBMSes support some high-end feature, writing a stored procedure that works on Oracle is quite different than writing a stored procedure that works on MS SQL Server. Shoot, even something as stupidly simple as creating an auto incrementing column is implemented differently between Oracle and MS SQL Server, neither of which could be considered "crappy" in terms of high-end features.
So think what you will, but out in the real world, if I can code to the lowest common denominator to avoid writing three, four, or five different versions of my application, unless there's some pretty extreme performance to be gained, that's what I'm going to do.
Oh, and if I'm coding my application to work across MS SQL Server and Oracle without modification, there's a really good chance it will work on pretty much every DBMS, including MySQL.
Arguing technical merit with a bunch of folks whose largest programming project is setting up some dumb ass blog or some shitty PHP website is pointless.
Getting back to your points, The only reason mysquirrel is popular is that it's easy to get up and running. Let's face it, the majority of apps that use it are shitty blog or message board software. I read one that just to show the list of forums it needs to run 13 queries! The 'joins are hard' and 'transactions are slow' crowd are the ones that use it.
I like the idea of just having a transparent layer in the language that wraps around whatever datastore you're using. I like the idea behind LINQ (Language Integrated Query), which is a Microsoft thing in C# 3.0 that basically lets you use SQL type queries on any "Set" of objects, be it a relational database table or tables, flat file or even arrays and data structures. Although it's kindof clunky, it might work for building prototypes because you don't have to worry about the data store, just the types. There is a similar project for Ruby called Ambition which looks pretty cool also.
Now, I know ODBC was supposed to do abstraction to a pretty full level, but to add arrays is the kicker for me. It's not efficient at all, but it make sense from a human perspective. That means it's easier to write code. I know Drupal and a few other CMS systems use a database abstraction layer (sort of), that will translate queries into whatever database you're using. It's not perfect, though. I know I'm always writing tons of functions in PHP to get the SQL the hell offa my page. Prepared statements and procedures are ok for that also. And if I want a lightweight SQL server, there's SQL Lite already!
Anyway, a better use of time would be to bring LINQ to this side of the street. I really think M$FT has something, for once. I mean, I saw a demo where they did a full AJAX app in about 10 minutes, you can run the query, joining a SQL query (adapter) with an array you already had, and maybe union that with an XML file and return the result as, well, you can return ANY data type you can bring in; so you could return a SQL resultset, or an array or XML or JSON or whatever you want. It handles MOST of the fuss for you. You have to do some mapping ahead of time but you can use XSD or a mapping array or a SQL JOIN table......... It's a universal adapter. BRING ONE TO PHP or at least RUBY. Or I could deal with a Python version.
Cool! Amazing Toys.
The fact that PostgreSQL supports inheritance, a cool feature MySQL doesn't support, hardly makes it hackish. Likewise, different doesn't equate to bad.
Better how?
Given that tons of posts on PostgreSQL's merits over that MySQL every time MySQL is brought up, I'll not rehash the long list of merits and technical reasons. They are plenty easy to find and lengthy to boot. The fact that you ask really seems trollish at best. Nonetheless, I'll continue.
The apps I use are designed to be write rarely, read often, and all I need is good performance on the read, a reasonable relational structure, and the
This used to be MySQL's sweet spot over that of PostgreSQL and is no longer. This rational alone is no longer reason enough to justify use of MySQL. Of course there are other factors, such as comfort, but this is no longer a MySQL advantage.
ability to do reasonably complex SQL queries.
MySQL's query planner/optimizer is well known to be primitive at best. PostgreSQL on the other hand has a very advanced, mature, highly configurable, and capable query planner. If you're doing complex SQL queries, very likely you'll be far better off with PostgreSQL.
As I originally said, unless you actually try PostgreSQL you'll never know what your missing out on. Ultimately your position is one of closing your eyes and humming so you don't have to leave your comfort zone. If you decide you want to expand your horizons and can approach it with an open mind, you'll very likely be kicking your self that you stayed with MySQL for so long.
The documentation is readily available and of high quality. Books are available. Third party support is also available. Unlike MySQL, it's easy to actually speak with and exchange emails of the actual core developers. In other words, third tier support is fast, friendly, easy, and accessible.
Thus far you seem to have made the case to try PostgreSQL.
Why would anyone in their right mind set up a Web/SQL platform using MS products?
I don't know, maybe the fact that IIS hasn't had a single criticle security vulnerability in 5 years, compared to several in Apache? Maybe the fact that the asp.net is a feature rich and fast platform with lots of third party support? Maybe the fact that Millions of developers are already familiar with the platform, languages, and characteristics?
Just a thought...
If you need web hosting, you could do worse than here
Actually, yes. Everybody needs a full ACID compliant transactional database, however, many people don't use those features (even though they should, and are complete morons for not doing so). So basically, Everyone needs it, not everyone wants it.
Web apps in particular need concurrency, transactions, stored procedures to be robust and reliable (not to mention safe). Those people that don't use those features are creating unreliable, unstable, unsafe software that won't stand up to the issues faced by web apps. 90% of Web app developers don't take things like multiple concurrent record access into account when they write their code, then it crashes or corrupts data in weird ways when they least expect it.
If you need web hosting, you could do worse than here
Nothing without a decent command line is "easy to develop for in my book
You might want to come into this century. http://en.wikipedia.org/wiki/Windows_PowerShell
And yes, IIS and ASP.NET are very easy to develop for. You can download the free Visual Studio Express, Free Sql Server Express, and have web pages up and running in seconds after installation. This gives you the ability to use a debugger to debug web pages and many other features that are a real pain in the ass to get working in the patchwork tools required for PHP and JSP or even RoR. No configuration needed.
Certainly, developing non-trivial web applications is just as difficult over the long haul, but the Microsoft tools make it VERY easy to get started.
If you need web hosting, you could do worse than here
Why?? Both PostgreSQL and MySQL are install and forget, unless you need absolute top performence in which case you might need to do special magic to spread the data and log files on different partitions.
This time it's based on InnoDB
-- "As a human being I claim the right to be widely inconsistent", John Peel