Valhalla Legends Archive

Quote from: Arta[vL] on June 12, 2003, 10:47 AM
Enumerate, please, the ways in which MySQL is shitty.

From what I've heard, it doesn't scale well to large databases.

Quote from: Skywing on June 12, 2003, 01:06 PM

Quote from: Arta[vL] on June 12, 2003, 10:47 AM
Enumerate, please, the ways in which MySQL is shitty.

From what I've heard, it doesn't scale well to large databases.

It'd be hard to argue that Google is not a large database.

Quote from: Grok on June 12, 2003, 01:08 PM

Quote from: Skywing on June 12, 2003, 01:06 PM

Quote from: Arta[vL] on June 12, 2003, 10:47 AM
Enumerate, please, the ways in which MySQL is shitty.

From what I've heard, it doesn't scale well to large databases.

It'd be hard to argue that Google is not a large database.

Do you know for a fact that they use MySQL, or SQL at all? I've never read anything about that.

Quote from: Skywing on June 12, 2003, 01:10 PM

Quote from: Grok on June 12, 2003, 01:08 PM

Quote from: Skywing on June 12, 2003, 01:06 PM

Quote from: Arta[vL] on June 12, 2003, 10:47 AM
Enumerate, please, the ways in which MySQL is shitty.

From what I've heard, it doesn't scale well to large databases.

It'd be hard to argue that Google is not a large database.

Do you know for a fact that they use MySQL, or SQL at all? I've never read anything about that.

Yes.  It has been discussed on Slashdot, and it is bragged about on MySQL:

http://www.mysql.com/company/factsheet.html

"Customers:
The MySQL database has an estimated 4 million active installations worldwide, and over 30,000 copies of MySQL are downloaded per day. Major corporations such as Yahoo!, Cisco, NASA, Lucent Technologies, Motorola, Google, Hyperion, and Sony Pictures rely on MySQL."

In that case...

QuoteSearched the web for x.   Results 1 - 10 of about 213,000,000. Search took 0.06 seconds.

Seems to scale pretty nicely to me

Quote from: Skywing on June 12, 2003, 01:06 PM
From what I've heard, it doesn't scale well to large databases.

Supposedly MySQL is more lowtech in queries too. On the other hand it's faster than a lot of other databases. The feeling I have is that if you want a fast database and can do with the operations MySQL supports, MySQL is for you. If you want a completer database (better support for SQL language) you'll want to get postgresql. But I'm in no way an expert on databases.

Quote from: herzog_zwei on June 12, 2003, 06:15 AM
 iptables -A BAD -p icmp --icmp-type echo-request -m limit --limit 4/s --limit-burst 10 -j RETURN
 iptables -A BAD -p icmp --icmp-type echo-request -j ATTACKED

That's an excellent way to handle pings. Like I've said before - there's nothing inherently wrong with icmp or pings. It's as abusable as most other protocols, and it has a good use.

Wouldn't you much prefer your webserver being pinged by an icmp ping packet rather than a TCP syn packet? Even if you use syn cookies, a ping should incur less overhead.

Quote from: Skywing on June 12, 2003, 01:06 PM
From what I've heard, it doesn't scale well to large databases.

Yes and no.  If you're mostly using it as a read-only database, it'd probably give you very good performace.  If you decide to write to a large database, it can be extremely slow.  The main problem why it didn't scale well before was because it used table locking instead of row-level locking, which is horrible when you decide to update a table with GBs of data.  Recent versions support transactional based tables which also allow you to do row-level locking.  However, you must specify it as a transactional table and not a standard MySQL one when you create that table.  One problem with the transactional tables is it's more of a wrapper to a different transactional database usng the MySQL interface, making it a bit harder to maintain.

The great thing about MySQL is that it supports many different types of tables within the same database volume.  You can use the slow transactional ones (for important things like billing info), the faster non-transactional disk based ones (for data that you need to keep but are willing to risk losing/corrupting for the extra speed), or even very fast, temporary memory based ones (for things like keeping track of sessions for a web server).

If you want a fast database that'll mostly process read-only data, MySQL would be something to look at (MySQL's website didn't specify what Google was using MySQL for but I'd guess they were using it because of the price and for the raw speed for mostly static data (they probably have scheduled times on each cluster of servers that they use to update the database, but for the majority of each day, it'll only be reading data)).  I'm not sure how well MySQL scales in read/write mode with transactions and row-level locking, but it should definitely be better than locking out an entire table.  If you want a really reliable database (uptime and consistency/integrity of data) that you'd be willing to risk your job for, MySQL probably wouldn't be on the top of your list.

MySQL's future looks good so check up on it from time to time.    For most people, it's more than they'll need.  It's
also affordable/cheap if you need to use it in commercial settings.  If you want something that's great at most things and don't care about the cost, look at Oracle.  If you want a free database, use Postgres; it's a decent database and considered to be safer to use than MySQL.  It's progressing as well, but not as fast as MySQL is.

MySQL does not support stored procedures. Now how shitty is that? (rhetorical question) Very!

PostgreSQL is nice.

Nice!  PostgreSQL supports PL/pgSQL now instead of requiring you to make shared object files and having PostgreSQL hook into them (which is a neat way of doing things and it's powerful enough to enable you to create a cheap man's version of real-time DB replication (something I attempted before PostgreSQL supported replication)).

I haven't found it absolutely necessary to use stored procedures but it can certainly make life easier.  It also doesn't necessarily make it portable like what some people think.  It's not in MySQL now but from their pages:

QuoteNew Features Planned For 5.0:

Stored Procedures

       * Stored procedures are currently being implemented. This effort is based on SQL-99, which has a basic syntax similar (but not identical) to Oracle PL/SQL. We will also implement the SQL-99 framework to hook in external languages, and (where possible) compatibility with e.g. PL/SQL and T-SQL.

My first choice of a DB for small tasks would still be MySQL since I can deal with not being able to use stored procedures (just implement procedures in code instead of in the DB).  In a polished application/util, you shouldn't give users direct access to the DB anyway.

No stored procedures?!  Can't possibly use that at the office.

Does it support constraints?
Triggers?
Cascaded triggers?
Column arrays?  (MSSQL does NOT, Oracle DOES)
Temporary tables?
Table datatypes?
Windows authentication?
Active Directory?

Save me some research

MySQL:

Constraints?  Yes with InnoDB tables, not yet if without.
Triggers?  No, but it's planned.
Temporary tables?  Yes.

PostgreSQL:

Constraints? Yes.
Triggers? Yes.
Cascaded triggers?  If you're referring to things like on delete/update/etc cascade, then yes.  Otherwise I'm not sure.  Same answer applies with MySQL using InnoDB).
Temporary tables?  Yes.

I'm not sure what you mean by column arrays, but if that's the same as being able to store an array of data in a field, then I believe the answer is yes for both.

As for table datatypes, windows authentication, and active directory, I don't think those are natively supported in either one.  I wouldn't doubt that people have added front ends to make the DBs work with Windows authentication.

Thanks.  I've been adequately educated to give MySQL much more time to mature.

Excuse my newbness, but what are stored procedures?

Quote from: St0rm.iD on June 17, 2003, 02:48 PM
Excuse my newbness, but what are stored procedures?

No problem.  From "Inside SQL Server 2000" by Kalen Delaney --

"Simply put, stored procedures and functions are collections of SQL statements stored in a SQL Server database.  You can write complex queries and transactions as stored procedures and then invoke them directly from the front-end application.  Whenever an ad hoc SQL command is sent to a database server for processing, the server must parse the command, check its syntax for sense, determine whether the requester has the permissions necessary to execute the command, and formulate an optimal execution plan to process the request.  Stored procedures and functions execute faster than batches of dynamic SQL statements, sometimes dramatically faster, because they eliminate the need to reparse and reoptimize the requests each time they're executed."

So, essentially, they're precompiled routines where the server has a darn good execution plan already figured out.  Thus, much faster (for the initial invokation) than passing a statement the server is seeing for the first time.

HTH,
Grok.