[quote author=Arta[vL] link=board=6;threadid=365;start=15#msg12172 date=1055432851]
Enumerate, please, the ways in which MySQL is shitty.
[/quote]
From what I've heard, it doesn't scale well to large databases.

[quote author=Skywing link=board=6;threadid=365;start=15#msg12178 date=1055441192]
[quote author=Arta[vL] link=board=6;threadid=365;start=15#msg12172 date=1055432851]
Enumerate, please, the ways in which MySQL is shitty.
[/quote]
From what I've heard, it doesn't scale well to large databases.
[/quote]

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

[quote author=Grok link=board=6;threadid=365;start=15#msg12179 date=1055441330]
[quote author=Skywing link=board=6;threadid=365;start=15#msg12178 date=1055441192]
[quote author=Arta[vL] link=board=6;threadid=365;start=15#msg12172 date=1055432851]
Enumerate, please, the ways in which MySQL is shitty.
[/quote]
From what I've heard, it doesn't scale well to large databases.
[/quote]

It'd be hard to argue that Google is not a large database.
[/quote]
Do you know for a fact that they use MySQL, or SQL at all? I've never read anything about that.

[quote author=Skywing link=board=6;threadid=365;start=15#msg12180 date=1055441448]
[quote author=Grok link=board=6;threadid=365;start=15#msg12179 date=1055441330]
[quote author=Skywing link=board=6;threadid=365;start=15#msg12178 date=1055441192]
[quote author=Arta[vL] link=board=6;threadid=365;start=15#msg12172 date=1055432851]
Enumerate, please, the ways in which MySQL is shitty.
[/quote]
From what I've heard, it doesn't scale well to large databases.
[/quote]

It'd be hard to argue that Google is not a large database.
[/quote]
Do you know for a fact that they use MySQL, or SQL at all? I've never read anything about that.
[/quote]

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...
[quote]Searched the web for x. Results 1 - 10 of about 213,000,000. Search took 0.06 seconds. [/quote]
Seems to scale pretty nicely to me :)

[quote author=Skywing link=board=6;threadid=365;start=15#msg12178 date=1055441192]
From what I've heard, it doesn't scale well to large databases.
[/quote]

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 author=herzog_zwei link=board=6;threadid=365;start=15#msg12164 date=1055416509]
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

[/quote]

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 author=Skywing link=board=6;threadid=365;start=15#msg12178 date=1055441192]
From what I've heard, it doesn't scale well to large databases.
[/quote]

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:

[quote]New 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.
[/quote]

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 :P

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 author=St0rm.iD link=board=6;threadid=1638;start=0#msg12526 date=1055879308]
Excuse my newbness, but what are stored procedures?
[/quote]

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.

Ah. Thanks.

Grok, y'know, I'm starting to see where you're coming from with this ASP.NET + SQL Server vs PHP + MySQL.

Overall, I think ASP.NET + SQL Server would kick the shit out of PHP+MySQL for stuff like Amazon.com, while something like sclegacy.com or a lesser volume site would be well suited to PHP/MySQL since it's cheap, fast, and easy.

Easy now, or I'll +1 you.

Well in that case...

ASP SUCKS! FREEBSD FOR LYFE!!!!!!!!!!!!!! DIE BILL DIE

*roasts St0rm*

Open up MS Access and create a couple dummy tables. Then go and mess with the queries. Queries basicly do the same thing as stored procedures (and are treated as stored procedures, as well).

[quote author=Camel link=board=6;threadid=1638;start=15#msg14311 date=1057779704]
Open up MS Access and create a couple dummy tables. Then go and mess with the queries. Queries basicly do the same thing as stored procedures (and are treated as stored procedures, as well).
[/quote]

To someone taking their first look at the SQL language, what you say could appear to be true. Stored procedures are not just queries though, they are actually procedures. They can take a number of parameters, call other functions and procedures, including extended procedures, and have conditional, branching, and looping constructs available for getting the job done. Their return can be multiple values as well as multiple rowsets and other objects.

In addition, stored procedures are typically precompiled by the host database, so that they use the most efficient optimization in the execution plan. Simple text queries like you have in MS Access only scratch the surface of stored procedures abilities.

Access has VBA -- customized functions can be used in queries. Not as good as stored procedures, but just as much can be accomplished.

[edit] BTW, Bump!

Camel, I have used VB and MS-Access since 1994, and SQL since 1996.

Just as much cannot be accomplished with any query passed from a client, except if that call is CREATE PROCEDURE. In that case, you are creating a stored procedure and no longer using client-sided queries.

Stored procedures provide the complete ability of the server to the programmer.

Try writing a single MS-Access query that deletes 500 rows that are older than 30 days, until there is nothing else old enough to delete, then exits, returning the number of rows deleted.

Now imagine writing that one query to do similar, but not the same work, to 25 tables. Add transactions to that and your query has no chance. But it is still trivial in a stored procedure.

Did you take the SQL courses at the URLs I posted last month? If not, you really should. I think your eyes would be opened to the power of server-side SQL programming when you use that training in stored procedures.

SQL Books Online is the best reference you could ever need. It's probably the most useful and complete work produced by Microsoft for any of their products.

One could write a VBA function to do all of that. Then, "SELECT myfunction(columns) FROM tables;"
I specificly said this method is not as practical (I used the word 'good') as stored procedures are. My point was that it's possible to do in Access, as you alluded that it was impossible.

[quote author=Camel link=board=6;threadid=1638;start=15#msg19835 date=1062539422]
One could write a VBA function to do all of that. Then, "SELECT myfunction(columns) FROM tables;"
I specificly said this method is not as practical (I used the word 'good') as stored procedures are. My point was that it's possible to do in Access, as you alluded that it was impossible.
[/quote]

That is precisely my contention -- that there are things possible to do in stored procedures that are impossible to do in a SELECT statement in MS-Access.

Conclusion: MS Access queries are the retarded siblings of stored procedures.

[quote author=Grok link=board=6;threadid=1638;start=15#msg19840 date=1062541183]
That is precisely my contention -- that there are things possible to do in stored procedures that are impossible to do in a SELECT statement in MS-Access.
[/quote]

If it's possible to write and use a VBA function like that in MS Access, then it seems to me that you cannot do anything more in a MSSQL SELECT than what you can do in an Access SELECT. It wouldn't surprise me if it's actually easier to do some things with an Access SELECT, like, say, putting up a GUI asking the user for input.

Very true. In fact, if you use a variable that doesn't exist, it will pop up an input box with the name of the variable and a text box, expecting you to type in the value. I used this a while back when I wrote a database for someone in charge of enrolling customers in different courses. Queries for reports looked something like:
[quote]SELECT * FROM Courses, Customers INNER JOIN Events ON (Courses.ID = Events.EventID) AND (Customers.ID = Events.CustomerID) WHERE Courses.CourseName LIKE [Enter course name];[/quote]