On 2006.04.06, Bas Scheffers <[EMAIL PROTECTED]> wrote:
> Dossy Shiobara said:
> > You're right; MySQL is orders of magnitude better than Sybase. I'm dead
>
> Yeah, when it doesn't blow up in weird and wonderul ways... [...]
I'll bet a nickel it's user error (whether that user is a developer or
the DBA).
> [...] And you don't mind not being able to do online backups.... [...]
Oh man, who is feeding you this pack of lies? I mean, MySQL has been
able to do hot online backups since May 2002! Well, you've been able to
do them for MyISAM table types much earlier than that, but the InnoDB
Hot Backup product reached version 1.00 in May 2002.
> [...] And if you think '0000-00-00' or '2006-02-30' is a date... (oh
> no, just tested mysql 5 silently turns the latter into '0000-00-00'!)
> [...]
There's a very good reason for this, AND if you find it objectionable,
you can even turn it off:
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-types.html
"MySQL also allows you to store '0000-00-00' as a "dummy date" (if
you are not using the NO_ZERO_DATE SQL mode). This is in some cases
is more convenient (and uses less space in data and index) than
using NULL values."
> [...] And expect 2 ints added together to form a value more than 32
> bits to be silently cast to a long... The list goes on and on.
My understanding is that the data type determines the number of
bits/bytes used at the storage layer, but all mathematics and aggregate
functions should operate at the highest precision and largest word size.
MySQL documents this:
http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html
"MySQL supports arithmetic with both signed and unsigned 64-bit
values. If you are using numeric operators (such as +) and one of
the operands is an unsigned integer, the result is unsigned. You can
override this by using the SIGNED and UNSIGNED cast operators to
cast the operation to a signed or unsigned 64-bit integer,
respectively."
If you want to truncate a value to 32-bits, your database should offer
you a way to do so. MySQL does, albeit a bit awkward:
mysql> select (pow(2, 32) + 8675309) << 32 >> 32;
+------------------------------------+
| (pow(2, 32) + 8675309) << 32 >> 32 |
+------------------------------------+
| 8675309 |
+------------------------------------+
> > T-SQL is so damn awful, it would probably be better off without any
> > stored procedure capability than to have it.)
> Some people feel the same about PL/SQL... Or that basterdazation of PL/SQL
> used in Postgres. T-SQL isn't perfect, but it has always gotten the job
> done for me quite easily and efficiently. Different strokes for differen
> folks.
I've done plenty of PL/SQL in Oracle from 7.3 through 9i, and T-SQL in
Sybase 11.5 through 12.5 -- both modern versions -- and given the
choice, I'd choose Oracle and PL/SQL over Sybase and T-SQL. That's my
personal preference, naturally, but one based on first-hand experience
with both.
> > Did you know that Sybase silently promotes an empty string to a string
> > of 1 character?
>
> Most database can't, they just silently make it NULL. Not sure which is
> worse...
Not being able to store a string of length 0 is worse.
> In fact, MySQL does *very* weird things with empty and semi-empty
> strings:
[...]
> Yes, those are 3 spaces in the where clause and MySQL returns rows with
> both empty strings and one space!
The row where you got one space back: I'd like to see how you inserted
the data. In general, this isn't weird at all, because ...
> Oh, and did you notice how it trims the values of char() columns?
Absolutely. MySQL trims trailing whitespace on CHAR values:
http://dev.mysql.com/doc/refman/5.0/en/string-type-overview.html
"Note: Trailing spaces are removed when CHAR values are retrieved."
...
"Note: Before 5.0.3, trailing spaces were removed when VARCHAR
values were stored, which differs from the standard SQL
specification."
> Does MySQL still use/support actual LOBs? (as in data stored elsewhere
> from the row) I thought everything was stored in-line and clob/blob was
> just a synonym for varchar(2B), just like in Postgres?
http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html
"[...] InnoDB stores the first 768 bytes of a VARCHAR, BLOB, or TEXT
column in the row, and the rest into separate pages."
If you want to use MyISAM and store the LOB data in a separate place,
you could manually do something similar to what Postgres does: store the
LOBs in the filesystem and generate a unique ID and just store that in
the row, or store the LOBs in a separate table and again, just store the
unique ID in the row.
> I don't mind anyone who prefers Oracle over Sybase. But to say MySQL
> is much better and more standards compliant just because you don't
> like a few things in Sybase (which, as it turns out MySQL isn't very
> good at either) is, well, a little strange.
The difference? If I *had* to, I could extend MySQL to do exactly what
I need. (Beware: Tcl as a supported UDF language for MySQL stored
procs! Muwahaha.)
-- Dossy
--
Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
