By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,598 Members | 1,498 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,598 IT Pros & Developers. It's quick & easy.

database in python ?

P: n/a
Hello I need to build table which need searching data which needs more
power then dictionary or list in python, can anyone help me what kind
of database suitable for python light and easy to learn. Is mySQL a
nice start with python ?

Sincerely Yours,
Pujo

Jul 18 '05 #1
Share this Question
Share on Google+
23 Replies


P: n/a
aj****@gmail.com wrote:
I need to build table which need searching data which needs more
power then dictionary or list in python, can anyone help me what
kind of database suitable for python light and easy to learn. Is
mySQL a nice start with python ?


You could try SQLite for Python: <http://pysqlite.org/>.

Cheers,

--
Klaus Alexander Seistrup
Magnetic Ink, Copenhagen, Denmark
http://magnetic-ink.dk/
Jul 18 '05 #2

P: n/a
MySQL is an excellent option is very well documented. It is also a
defacto standard for OpenSource databases.

You will need to install the Python module MySQLdb. -->
http://sourceforge.net/projects/mysql-python

There should be plenty of examples online too for using MySQLdb with
Python.

If you get more advanced, you can look into the SQLObject module which
allows you to use databases in a more Pythonic objective way.

Julian
http://julianyap.blogspot.com

Jul 18 '05 #3

P: n/a
MySQL is an excellent option is very well documented. It is also a
defacto standard for OpenSource databases.


MySQL sucks for anything but very very basic stuff as it supports no
transactions, foreign keys, procedures, triggers, concurrency, etc.
Postgresql is a lot better, free, and the psycopg adapter for Postgres is
*very very* fast (a lot faster than the MySQL one) and it has a
dictfetchall() method which is worth its weight in donuts !
Jul 18 '05 #4

P: n/a
Pierre-Frédéric Caillaud wrote:
MySQL is an excellent option is very well documented. It is also a
defacto standard for OpenSource databases.



MySQL sucks for anything but very very basic stuff as it supports
no transactions, foreign keys, procedures, triggers, concurrency, etc.
Postgresql is a lot better, free, and the psycopg adapter for
Postgres is *very very* fast (a lot faster than the MySQL one) and it
has a dictfetchall() method which is worth its weight in donuts !


MySQL has support for transactions and foreign keys in it's InnoDB
engine. In 5.0 it supports views procedures. Some people seems to hate
MySQL :-) but a whole lot of other people like it a lot.

The thing is, if you don't spesificaly state that you want triggers,
concurrency and procedures I guess that your needs are quite basic.

However you won't be be disappointed with either MySQL or postgree in
your trunk :)

ola

--
--------------------------------------
Ola Natvig <ol********@infosense.no>
infoSense AS / development
Jul 18 '05 #5

P: n/a
aji...@gmail.com wrote:
I need to build table which need searching data which needs more
power then dictionary or list in python, can anyone help me what
kind of database suitable for python light and easy to learn. Is
mySQL a nice start with python ?


It depends... mySQL is fine for more or less data centric applications
with many tables.

When I need SQL search power, but the number of tables/records is small
enough gadfly is the best bet. Contact database, CD catalog, extended
configuration data are proper examples. In such cases, gadfly is by far
faster, then "normal" relational databases.

Jul 18 '05 #6

P: n/a
In article <11*********************@z14g2000cwz.googlegroups. com>,
"aj****@gmail.com" <aj****@gmail.com> wrote:
Hello I need to build table which need searching data which needs more
power then dictionary or list in python, can anyone help me what kind
of database suitable for python light and easy to learn. Is mySQL a
nice start with python ?

Sincerely Yours,
Pujo


MySQL lacks some of the more advanced features of commercial SQL databases
like Oracle or Sybase, but other than that, it's an excellent and very
popular choice.

It's free, easy to install, runs on many platforms and has interfaces to
many languages (including Python). It's also been around a long time and
used on many large-scale projects, so you can have confidence that it's
stable. It's also well documented, both with on-line material from the
makers, and from third party publishers (I like the O'Reily book).
Jul 18 '05 #7

P: n/a
"aj****@gmail.com" <aj****@gmail.com> said :
Hello I need to build table which need searching data which needs more
power then dictionary or list in python, can anyone help me what kind
of database suitable for python light and easy to learn. Is mySQL a
nice start with python ?


There are a number of separate database engines with a python interface, as
others in the thread have shown. However, if you mostly work with one table
at a time, as you seem to imply, then you might have a look a Kirbybase :
it's a single python module, and databases don't come any lighter or easier
than that :)

--
YAFAP : http://www.multimania.com/fredp/
Jul 18 '05 #8

P: n/a

If you want Simple you can use the following piece of code.
It won't work if you have a million records, but it's a nice intelligent
flatfile storage with a select where + order by and limit emulator.

# ################################################## #######

class ListMgr( object ):
def __init__( self, klass, filename ):
self.filename = filename
self.klass = klass
self.load()

def load( self ):
try:
self.contents = pickle.load( open( self.filename ))
print "Loaded %d items %s in %s" % (len(self.contents), self.klass,
type(self))
except IOError:
print "Creating new contents for", type(self)
self.contents = {}
self.save()

if self.contents:
self.insert_id = max( self.contents.keys() ) +1
else:
self.insert_id = 1

def save( self ):
pickle.dump( self.contents, open( self.filename+'.tmp', 'w' ) )
os.rename( self.filename+'.tmp', self.filename )
print "Saved %d items %s in %s" % (len(self.contents), self.klass,
type(self))

def new( self, **params ):
return self.klass( **params )

def insert( self, obj ):
assert not hasattr( obj, 'id' ) or obj.id is None
obj.id = self.insert_id
self.insert_id += 1
self.contents[obj.id] = obj

def update( self, obj ):
assert obj.id is not None
self.contents[obj.id] = obj

def select( self, id ):
return self.contents[ id ]

def delete( self, id ):
del self.contents[ id ]

def count( self ):
return len( self.contents )

# where is a lambda function, order_by is a cmp function, limit is a slice
def select_multiple( self, where=None, order_by=None ):
if where:
c = filter( where, self.contents.itervalues() )
else:
c = self.contents.values()
if order_by:
c.sort( order_by )
return c

# ################################################## #######

class ListEntry( object ):
def __init__( self, **params ):
self.__dict__ = dict.fromkeys( self.get_fields() )
self.__dict__.update( params )

def get_fields( self ):
return ()

def display( self ):
print '-'*40
if hasattr( self, 'id' ):
print "id :",self.id
for k in self.get_fields():
print k," :",getattr(self,k)
print

# ################################################## #######

class AddressBookEntry( ListEntry ):
def get_fields( self ):
return 'name', 'address', 'zipcode', 'city', 'country', 'phone'
get_fields = classmethod( get_fields )

class AddressBook( ListMgr ):
def __init__( self, fname ):
super( AddressBook, self ).__init__( AddressBookEntry, fname )

Jul 18 '05 #9

P: n/a
On Monday 11 April 2005 11:01, Pierre-Frédéric Caillaud wrote:
psycopg ... has a dictfetchall() method which is worth its weight in
donuts !


It's very simple to write one for MySQLdb:

def dictfetchall(cursor):
'''Takes a MySQLdb cursor and returns the rows as dictionaries.'''
col_names = [ d[0] for d in cursor.description ]
return [ dict(zip(col_names, row)) for row in cur.fetchall() ]

In truth, although postgres has more features, MySQL is probably better for
someone who is just starting to use databases to develop for: the chances are
higher that anyone using their code will have MySQL than Postgres, and they
aren't going to need the features that Postgresql has that MySQL doesn't.
IMO, this has changed since only a year or two ago, when MySQL didn't support
foreign-key constraints.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCWoacY6W16wIJgxQRAnbTAJ9g+gSEc9/fKBbVVuAKPaKq0BaPrwCghAcX
y6TFDJYn6AzIMmnPbc1EMrM=
=b4eV
-----END PGP SIGNATURE-----

Jul 18 '05 #10

P: n/a
Pierre-Frédéric Caillaud wrote:
MySQL is an excellent option is very well documented. It is also a
defacto standard for OpenSource databases.
MySQL sucks for anything but very very basic stuff as it supports no

transactions,
Transactions available since 3.23.17 (June 2000)
foreign keys,
Foreign keys available since 3.23.44 (Oct 2001)
procedures,
Stored procedures available since 5.0 (5.0.3 is the current beta)
triggers,
Triggers available since 5.0.2
concurrency, etc.
Who knows what *this* means. Anyone who thinks MySQL can't handle
multiple concurrent connections is clearly delusional or ignorant.
Postgresql is a lot better, free, and the psycopg adapter for Postgres is *very very* fast (a lot faster than the MySQL one) and it has a
dictfetchall() method which is worth its weight in donuts !


Postgresql is also a fine database. But note that MySQLdb (the Python
adapter) also has an equivalent mechanism for returning rows as
dictionaries. As for speed: I don't do any benchmarking, but there
should be no substantial speed differences between the two interfaces.

Jul 18 '05 #11

P: n/a
Ola Natvig wrote:
MySQL has support for transactions and foreign keys in it's InnoDB
engine. In 5.0 it supports views procedures. Some people seems to hate
MySQL :-) but a whole lot of other people like it a lot.


There are other problems, such as failing silently in many
circumstances, as documented on http://sql-info.de/mysql/gotchas.html.
I'm not saying these issues should make one avoid MySQL at all costs,
but I think one should at least be aware of them.

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven
Jul 18 '05 #12

P: n/a
Pierre-Frédéric Caillaud wrote:
MySQL is an excellent option is very well documented. It is also a
defacto standard for OpenSource databases.

MySQL sucks for anything but very very basic stuff as it supports
no transactions, foreign keys, procedures, triggers, concurrency, etc.
Postgresql is a lot better, free, and the psycopg adapter for
Postgres is *very very* fast (a lot faster than the MySQL one) and it
has a dictfetchall() method which is worth its weight in donuts !


While I wouldn't necessarily disagree with your assessment of the
relative merits of those two databases your information about MySQL is
somewhat out of date - for example, it has supported transactions for
almost two years now.

regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 18 '05 #13

P: n/a
Pierre-Frédéric Caillaud wrote:
MySQL is an excellent option is very well documented. It is also a
defacto standard for OpenSource databases.

MySQL sucks for anything but very very basic stuff as it supports
no transactions, foreign keys, procedures, triggers, concurrency, etc.
Postgresql is a lot better, free, and the psycopg adapter for
Postgres is *very very* fast (a lot faster than the MySQL one) and it
has a dictfetchall() method which is worth its weight in donuts !


Yes, Postgresql is a lot better than MySQL but take a look at Firebird
to see how easy a full featured db-System could be.
Use kinterbasdb from Sourceforge to get Firebird into Python.

Uwe
Jul 18 '05 #14

P: n/a
> In truth, although postgres has more features, MySQL is probably
better for someone who is just starting to use databases to develop
for: the chances are higher that anyone using their code will have
MySQL than Postgres, and they aren't going to need the features
that Postgresql has that MySQL doesn't. IMO, this has changed
since only a year or two ago, when MySQL didn't support foreign-key
constraints.


mysql does deserve serious consideration now that it supports
transactions. However, keep in mind:

1. mysql doesn't support transactions - one of its io layers (innodb)
does. If you're hoping to get your application hosted you will find
that most mysql installations don't support innodb. And due to the
bugs in mysql, when you attempt to create a transaction-safe table in
mysql if innodb isn't available it will just silently create it in
myisam, and your transactions will be silently ignored.

2. mysql is still missing quite a few database basics - views are the
most amazing omission, but the list also includes triggers and stored
procedures as well. Although most of these features are included in
the new beta, they aren't yet available in production.

3. mysql has an enormous number of non-standard features such as
comment formatting, how nulls work, concatenation operator, etc. This
means that you'll learn non-standard sql, and most likely write
non-portable sql.

4. additionally, mysql has a peculiar set of bugs - in which the
database will change your data and report no exception. These bugs
were probably a reflection of mysql's marketing message that the
database should do nothing but persist data, and data quality was the
responsibility of the application. This self-serving message appears
to have been dropped now that they are catching up with other products,
but there's a legacy of cruft that still remains. Examples of these
errors include: silent truncation of strings to fit max varchar
length, allows invalid dates, truncation of numeric data to fit max
numeric values, etc.

5. cost: mysql isn't expensive, but it isn't free either. Whether or
not you get to use it for free depends on how you interpret their
licensing info and faq. MySQL's recommendation if you're confused (and
many are) is to license the product or call one of their reps.

Bottomline - mysql has a lot of marketshare, is improving, and I'm sure
that it'll eventually be a credible product. But right now it's has a
wide range of inexcusable problems.

More info at http://sql-info.de/mysql/gotchas.html

buck

Jul 18 '05 #15

P: n/a
Bottomline - mysql has a lot of marketshare, is improving, and I'm sure
that it'll eventually be a credible product. But right now it's has a
wide range of inexcusable problems.
I so totally agree with you.
I find that mysql promotes bad coding practices by ignoring errors and
substituting invalid data with factory defaults. If it complained when an
obvious error occured (like inserting an invalid date or saying "I can't
fit this data in this column") it would be easy to find the bug ; instead
it shows up months later in creepy ways when you realize part of your data
was truncated, or otherwise screwed up in quite imaginative ways, and you
have to fix the damn thing by hand, burning your eyes on phpmyadmin
screens.
Also most of the interesting features are in the Beta 5.0 !
I find it ironic that it's the biggest open source database while there
are a lot of really free alternatives like firebird or postgres, which
have all the good features Right Now, and which Just Work. There is also a
lot of marketing hype and frankly I have no trust at all in a company
which was making public statements like "Who needs foreign keys ?" just
because their product didnot supports them, then when it supports them,
changing their PR to match.
More info at http://sql-info.de/mysql/gotchas.html
buck

Jul 18 '05 #16

P: n/a
Buck Nuggets wrote:
1. mysql doesn't support transactions - one of its io layers (innodb) does. If you're hoping to get your application hosted you will find
that most mysql installations don't support innodb. And due to the
bugs in mysql, when you attempt to create a transaction-safe table in
mysql if innodb isn't available it will just silently create it in
myisam, and your transactions will be silently ignored.
That's not a bug; it's an explicitly-stated design choice.

http://dev.mysql.com/doc/mysql/en/create-table.html

If a storage engine is specified that is not available, MySQL
uses MyISAM instead.
2. mysql is still missing quite a few database basics - views are the most amazing omission, but the list also includes triggers and stored
procedures as well. Although most of these features are included in
the new beta, they aren't yet available in production.
Views, triggers, stored procedures are all available in 5.0.2 (beta).
3. mysql has an enormous number of non-standard features such as
comment formatting, how nulls work, concatenation operator, etc. This means that you'll learn non-standard sql, and most likely write
non-portable sql.
SET GLOBAL sql_mode='ansi'; and you won't have to worry about it.
4. additionally, mysql has a peculiar set of bugs - in which the
database will change your data and report no exception. These bugs
were probably a reflection of mysql's marketing message that the
database should do nothing but persist data, and data quality was the
responsibility of the application. This self-serving message appears
to have been dropped now that they are catching up with other products, but there's a legacy of cruft that still remains. Examples of these
errors include: silent truncation of strings to fit max varchar
length, allows invalid dates, truncation of numeric data to fit max
numeric values, etc.
MySQL gives warnings when data is truncated or misformatted.

http://dev.mysql.com/doc/mysql/en/mysql-info.html
http://dev.mysql.com/doc/mysql/en/my...ing-count.html
http://dev.mysql.com/doc/mysql/en/show-warnings.html

Since we're in comp.lang.python, MySQLdb-1.2 uses the warnings module
to alert you to this. MySQLdb-1.0 and earlier would raise a Warning
exception (or not, if you used a different cursor class).

Implicit default column values can disabled in 5.0.2 by running the
server in strict mode.

http://dev.mysql.com/doc/mysql/en/server-sql-mode.html
5. cost: mysql isn't expensive, but it isn't free either. Whether or not you get to use it for free depends on how you interpret their
licensing info and faq. MySQL's recommendation if you're confused (and many are) is to license the product or call one of their reps.
MySQL is licensed under the GPL. You can buy a commercial license if
you don't want the GPL's restrictions.

http://www.mysql.com/company/legal/licensing/
Bottomline - mysql has a lot of marketshare, is improving, and I'm sure that it'll eventually be a credible product. But right now it's has a wide range of inexcusable problems.


It's not a bug if you didn't RTFM.

Jul 18 '05 #17

P: n/a
> It's not a bug if you didn't RTFM.

Maybe it's not a bug if it's the only DBMS you've ever used and you
actually believe that overriding explicit & critical declaratives is a
valid "design choice". But it is a bug if it's still only partially
supported in a beta version that nobody is yet hosting.

But maybe this release will actually fix ten years of negligence in one
fell swoop - and all these issues will be easily eliminated. But just
in case that turns out to be difficult, and there's some reason it has
taken all this time to achive, just wait and see what this guys finds:
http://sql-info.de/mysql/gotchas.html

BTW, you should upgrade, they're now on 5.0.3. Their support site
appears to be down right now (timeouts) so I can't check the new bug
list, but since 5.0.2 is beta, it may have introduced more problems
than it solved.

buck

Jul 18 '05 #18

P: n/a
It's not a bug if you didn't RTFM.


I did read it in much detail !

In fact I spent a lot of time trying to make understand how it could do a
simple 4-table join to display also purchased products on an online store.
The damn query took 0.5 seconds to execute no matter how I twisted it in
and out !
Postgres did it in 0.5 milliseconds.
I had to split the query in two in the application !

Speaking of the manual, the mysql manual is quite... well... i don't
quite find the word, but it has many sentences which sound like PR stuff.
Like, we don't do this like you or anyone would expect, but there is a
reason ! Embrace our school of thought, stop worrying about integrity !
Peace, my friend, etc. And the non-working examples posted in the user
comments are nice to look at, too. The organization of the manual is a
mess, too, it's often quite difficult to find what I seek. The postgres
manual is just wonderful.

I know I'm feeding the flamewar, but I can't resist, once I came up on a
post on the mysql website from a guy basically saying "wow, the fulltext
is so powerful, I can search this document set in only half a second !"
and then the same day, on the postgres mailinglist, there was a message
from a guy who was really upset because his full text search on something
like 1000 times bigger would take more than one tenth a second, and that
wan't really acceptable for him, and then several competent people
responded and helped him make it work.

That's also why I want to use postgres.

Jul 18 '05 #19

P: n/a
Terry Hancock wrote:
[...]
That's interesting. Most sources I've read seemed to suggest that postgresql
is slower than MySQL, at least for modest size tables. There must, I suppose,
be some turnover point on the size of the database? Or are you arguing that
postgresql is now faster than MySQL in the general case? Can you suggest
sources for investigating that formally?

It's just possible that I should reconsider Postgresql compatibility. I
would assume that using the Python DB API would make portability
between the two easier in any case, wouldn't it?

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com


I don't know about the whole picture, but I know form evidence on this
group that there are PostgreSQL driver modules (the name "psycopg" comes
to mind, but this may be false memory) that appear to take diabolical
liberties with DBAPI-2.0, whereas my experience with MySQLdb has been
that I can interchange the driver with mxODBC (for example) as a drop-in
replacement (modulo the differing paramstyles :-().

regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/

Jul 18 '05 #20

P: n/a
>> postgresql
is slower than MySQL, at least for modest size tables. There must, I
When not using transactions, MySQL will blow away postgres in
INSERT/UPDATE speed until the concurrency gets up a bit and the readers
block writers strategy used by MyISAM starts to show its weaknesses.
This is in agreement with mass hosting for instance, a lot of small
databases on a mysql will not have concurrency problems.
Of course when not using transactions you have to remind that your data
is not secure, and any power crash might corrupt your database.
Postgres on a RAID with battery backed up cache will no longer have to
sync the disk on each transaction so it gets a lot faster, and you still
have data security. You can also run it with fsync=off for a massive
speedup in transactions per second but you lose data security.
When using transactions (innodb) I've read that postgres is a bit faster.
Regarding query optimization, for simple dumb queries like grabbing a row
from a table, mysql will be a little faster (say 0.2 vs 0.3 ms), and for
medium complex queries like joins on >= 4 medium sized tables (>10 K rows)
postgres can be faster by anything from 1x to 1000x. I've seen it happen,
the same query taking 0.5 seconds in my and 0.5 ms in postgres, simply
because mysql can't plan it correctly.
suppose,
be some turnover point on the size of the database? Or are you arguing
that
postgresql is now faster than MySQL in the general case? Can you

I'd suggest that on anything medium postgres will be a lot faster.
I don't know about the whole picture, but I know form evidence on this
group that there are PostgreSQL driver modules (the name "psycopg" comes
to mind, but this may be false memory) that appear to take diabolical
liberties with DBAPI-2.0, whereas my experience with MySQLdb has been
that I can interchange the driver with mxODBC (for example) as a drop-in
replacement (modulo the differing paramstyles :-().


psycopg is extremely fast and powerful, so it makes a lot more things
that the dbapi says.
I'd say that database independence is an utopia, once you start to use
triggers and stored procedures and specific column types, you'll be more
or less tied to one database, and doing this is necessary to get good
performance and generally do things right.
Jul 18 '05 #21

P: n/a
Andy Dustman wrote:

Transactions available since 3.23.17 (June 2000)

Transactions only supported on slow database types like innodb.

If you ever tried it you cannot say that mysql supports transactions. No.
Last time when I tried mysql 4.x did explicit commit if you simply
disconnected inside a transaction block. It was a year ago, but I will
never forget it.
foreign keys,


Foreign keys available since 3.23.44 (Oct 2001)

They are syntactically accepted but not forced.
procedures,
Stored procedures available since 5.0 (5.0.3 is the current beta)

It's a beta.

Postgresql is also a fine database. But note that MySQLdb (the Python
adapter) also has an equivalent mechanism for returning rows as
dictionaries. As for speed: I don't do any benchmarking, but there
should be no substantial speed differences between the two interfaces.


I have seen real benchmarks. MySQL 5 is slower than postgresql and it's
also slower than firebird if you do some real work.

Mage
Jul 18 '05 #22

P: n/a
Steve Holden wrote:
I don't know about the whole picture, but I know form evidence on this group that there are PostgreSQL driver modules (the name "psycopg" comes to mind, but this may be false memory) that appear to take diabolical liberties with DBAPI-2.0, whereas my experience with MySQLdb has been that I can interchange the driver with mxODBC (for example) as a drop-in replacement (modulo the differing paramstyles :-().


There are a couple reasons for the interchangability: Marc-Andre
Lemburg, the author of mxODBC, was also one of the main people involed
with the DB API spec (now PEP-249). MySQLdb was also written with the
spec in mind. One reason for this is that prior to writing MySQLdb, I
used mxODBC in an application I wrote, connecting to a database called
Solid: http://www.solidtech.com/

I don't think they sell the database as a separate product any more; at
least my memory from the late 90's is that they stopped doing that.

I've also done a bit of database work with pyscopg (a few years back),
and there's not a marked difference between that and MySQLdb, as I
recall. Parameter styles are the main difference between the three
(MySQLdb and psycopg use pyformat or %s, and mxODBC uses qmark or ?).
MySQLdb-1.4/2.0 will most likely support both styles as the latter is
what MySQL expects for the Prepared Statement API that is new in 4.1.
By "support both", I mean that you'll be able to configure at run-time
which style you want to use.

For feature comparisons, check out:

http://dev.mysql.com/tech-resources/crash-me.php

These comparisons are a little old, but you can compare MySQL-4.1.1
against PostgreSQL-7.3.3 and others.

If speed is a critical factor, get both (they're free), put in some
representative data for your application, and start benchmarking.

Jul 19 '05 #23

P: n/a
Mage wrote:
Andy Dustman wrote:

Transactions available since 3.23.17 (June 2000)

Transactions only supported on slow database types like innodb.

If you ever tried it you cannot say that mysql supports transactions.

No. Last time when I tried mysql 4.x did explicit commit if you simply
disconnected inside a transaction block. It was a year ago, but I will never forget it.
You know that the default server setting has autocommit on, right?
foreign keys,


Foreign keys available since 3.23.44 (Oct 2001)

They are syntactically accepted but not forced.


http://dev.mysql.com/doc/mysql/en/in...nstraints.html
http://dev.mysql.com/doc/mysql/en/error-handling.html

# Error: 1215 SQLSTATE: HY000 (ER_CANNOT_ADD_FOREIGN)
Message: Cannot add foreign key constraint

# Error: 1216 SQLSTATE: 23000 (ER_NO_REFERENCED_ROW)
Message: Cannot add or update a child row: a foreign key constraint
fails

# Error: 1217 SQLSTATE: 23000 (ER_ROW_IS_REFERENCED)
Message: Cannot delete or update a parent row: a foreign key
constraint
fails

Foreign keys work. Prior to 3.23, it was just syntactical support. But
that was 5 years ago.
I have seen real benchmarks. MySQL 5 is slower than postgresql and it's also slower than firebird if you do some real work.


So use the database that works best for your application. MySQL is not
a panacea, but there are a lot of applications it works well for.

Jul 19 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.