On Mon, 15 Mar 2010 08:49:34 +0100, David Tynnhammar wrote:
> Greetings. I'm looking for a "distributed" database. (I'm not sure if
> distributed is the correct terminology though).
>
> My problem is this; I have a client application which once in a while
> needs to sync with a central database.
Greetings. I'm looking for a "distributed" database. (I'm not sure if
distributed is the correct terminology though).
My problem is this; I have a client application which once in a while
needs to sync with a central database. (And of course the client
-databases might be updated locally etc).
Ar
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
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 My
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 i
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 i
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
On Tuesday 12 April 2005 04:54 pm, Pierre-Frédéric Caillaud wrote:
> 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
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
> 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 hostin
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 t
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 in
> 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
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,
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.
Postgre
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 d
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)
>
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_nam
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 ):
de
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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 ar
In article <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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
> n
[EMAIL PROTECTED] 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
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.
Postgre
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 psyc
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
[EMAIL PROTECTED] 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:
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
--
http://mail.python.org/mailman/listin
27 matches
Mail list logo