Em Sexta 28 Abril 2006 15:41, Robin Haswell escreveu:
>
> IMO "doing the right thing" would be an SQL error. The Zen of Python,
> errors shouldn't go unnoticed?
Except that the error is in MySQL, right? ;-) Truncating in SQL columns
should either be explicit or the server should raise an exception:
neo=# create table testest (testcol varchar(10));
CREATE TABLE
neo=# insert into testest (testcol) values ('12345678910');
ERRO: valor muito longo para tipo character varying(10)
neo=#
(ERROR: value too large for type character varying(10))
> Nah I disagree, MySQL is a great database as long as you are aware of the
> implications. MySQL tries to be an enterprise-class RDBMS, which it is not,
> however people who are familiar with it know the real truth: MySQL is
> blazingly fast BECAUSE of things like this. If you need 100% data integrity
> and advanced (read: rarely used) functionality then you use PG. If you want
I use PG ;-) I need to trust that all data inside the database *is* valid.
> "as fast as Oracle" you use MySQL. If you want both, you use Oracle or DB2.
I'd disagree... There are root servers (.org and .info) using PostgreSQL,
there are none using MySQL. Speed, in this case, is very important.
http://www.postgresql.org/about/users
and for Afilias article:
http://www.computerworld.com.au/index.php?id=760310963
I couldn't find the degradation graphic of PostgreSQL and MySQL for millions
of rows, but...
http://wiki.astrogrid.org/bin/view/Astrogrid/?topic=CrossMatchingReport&sortcol=1&table=1&up=0
http://feedlounge.com/blog/2005/11/20/switched-to-postgresql/
Of course, we can keep discussing that and for each article I point you to,
you can send me the double in favor of MySQL. And then, I can double you.
And ... :-)
Anyway, we're way off-topic here. If you want, I don't mind discussing this
in private.
> MySQL is the PHP of RDBMS, it's great for 99% of uses, but there are fringe
> cases where another database will be more appropriate. For me, this problem
How did you guess I don't like PHP as well? ;-)
> will not stop me using MySQL, I will just use TEXT columns when I want
> strings longer than 127 characters.
If it isn't bad for you, then I don't see any problem with that. In fact,
even for PG there are people that advocate the use of text columns anywhere
you need something bigger than 1 char (some even for the 1 char column ;-)).
> It should be important to note, by the way, that this poses a mild risk to
> applications: Someone could insert corrupt data into the database, which
> would result in the application crashing with a UnicodeDecodeError every
> time it tries to select that data.
This is also one of the reasons why integrity inside the database is crucial
and required. You have to trust that your data is safe and is correct, if
the RDBMS doesn't provide you that, I'm sorry, but it is not a good choice.
> I think, a solution to the crashing would be for SQLObject to encode
> UnicodeCol characters in to UTF-16, which is a 2-byte character set? So if
> you had even column lengths, then there is no chance of MySQL truncating
> the data in the middle of a character.
Why penalize everyone that uses a database server that works by requiring
twice the amount of space for a string like "this"? UTF-8 is a very good
choice since it only uses 2-byte chars when needed. You save disk space,
memory and other.
I am of the opinion that what is broken is what should be fixed, no matter how
many workarounds you can put in place to circumvent those failures.
I'm sorry for expressing my opinion and taking this debate to an off-topic
thread. I'll stop here and if you want, we can talk in private.
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
