Learning curve for new database program with Python?
Jetus
and reviewed some of the documentation.
My question is, what is the easiest program for me to try to learn. I
will be creating a database of about 25,000 records, it will be
relational. I am a beginner Python programmer, and need a database
solution that is easy to grasp. I played with sql,
and found that very difficult, if not overly cumbersome.
A database that could work with Django would be very interesting to
look at as well..
Any suggestions out there?
Dotan Cohen
I haven't used _any_ database with Python, but for PHP I found sqlite
to be very easy to work with. Take a look at it.
Dotan Cohen
http://what-is-what.com
http://gibberish.co.il
א-ב-ג-ד-ה-ו-ז-ח-ט-י-ך-כ-ל-ם-מ-ן-נ-ס-ע-ף-פ-ץ-צ-ק-ר-ש-ת
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Mensanator
You didn't mention the system you're using or whether
you require something that's free.
Microsoft Access is easy to learn. You can become very
productive without every needing to learn SQL. Of course,
you'll need to learn some SQL in order to interface to
Python. But the good news is you can use the MS-Access
drag-and-drop interface to learn how to set up the
relational queries and once it's running, you can
display the underlying SQL code to learn how to
use it in Python.
For example, I often design the queries in Access
(where I have the advantage of visual design) and
use simple SELECT calls from Python do retrieve
the data.
Michele Simionato
sqlite is arguably the simplest relational database out there,
and it is integrated with Python 2.5+. Of course you need to
tell us if an embedded database if enough for your use case,
or if you want a client-server database, if you use Windows
or Unix, if you want graphical administration tools or not,
what your final goal is, and so on.
Michele Simionato
John Nagle
> I have a need for a database program. I downloaded the db2 from ibm,
> and reviewed some of the documentation.
>
> My question is, what is the easiest program for me to try to learn. I
> will be creating a database of about 25,000 records, it will be
> relational. I am a beginner Python programmer, and need a database
> solution that is easy to grasp. I played with sql,
> and found that very difficult, if not overly cumbersome.
Basic SQL isn't that hard. Learn CREATE, SELECT, INSERT,
UPDATE, and DELETE syntax. That's enough for most simple
applications.
I'd suggest using sqlite if you're doing something that
runs as a single standalone application, and MySQL if there
are multiple users of the database or it's a web service.
IBM's DB2 or Oracle is overkill for 25,000 records.
Install MySQL and its graphical client, and play with
it a bit. Create a table, type in a few records, and
try various SELECT statements. That will give you a sense of how SQL works.
John Nagle
CM
From the good people at Django:
"If you want to use Django with a database, which is probably the
case, you'll also need a database engine. PostgreSQL is recommended,
because we're PostgreSQL fans, and MySQL, SQLite 3, and Oracle are
also supported."
And if you want to make it a relational database, pretty much it's SQL
as the language. And that's ok--it really is not hard at all, I
picked it up quick and I'm new to databases; it's rather like a
natural language. I've had success with keeping things simple with
Python + SQLite--just import
sqlite3 and use Python code such as:
cur.execute("SELECT name FROM customers WHERE city='Chicago'")
See here: http://docs.python.org/lib/module-sqlite3.html
Very straightforward. Don't know how Django interacts with these two,
but probably quite well, or you could choose from the other database
management engines listed above.
Simon Brunning
>
> Basic SQL isn't that hard. Learn CREATE, SELECT, INSERT,
> UPDATE, and DELETE syntax. That's enough for most simple
> applications.
Agreed. What's more, I've found SQL to be the single most transferable
skill in IT.. No matter what language and platform you find yourself
working on, you'll find an SQL driven relational database somewhere in
the mix. Learning SQL isn't a waste of time, I guarantee it.
--
Cheers,
Simon B.
si...@brunningonline.net
http://www.brunningonline.net/simon/blog/
M.-A. Lemburg
> On Sun, Apr 6, 2008 at 2:31 AM, John Nagle <na...@animats.com> wrote:
>> Basic SQL isn't that hard. Learn CREATE, SELECT, INSERT,
>> UPDATE, and DELETE syntax. That's enough for most simple
>> applications.
>
> stored procedures. You can do a lot of processing "inside" the database
> which cuts down on data running over the wire.
>
> SQL is one of the areas I wish I had mastered (much) earlier in my career
Fully agree :-)
Interesting comments in a time where everyone seems to be obsessed
with ORMs.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 07 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
bruno.des...@gmail.com
> On Apr 5, 11:50 am, Jetus <stevegi...@gmail.com> wrote:
>
> > I have a need for a database program. I downloaded the db2 from ibm,
> > and reviewed some of the documentation.
>
> > My question is, what is the easiest program for me to try to learn. I
> > will be creating a database of about 25,000 records, it will be
> > relational. I am a beginner Python programmer, and need a database
> > solution that is easy to grasp. I played with sql,
> > and found that very difficult, if not overly cumbersome.
>
> > A database that could work with Django would be very interesting to
> > look at as well..
>
> > Any suggestions out there?
>
> From the good people at Django:
>
> "If you want to use Django with a database, which is probably the
> case, you'll also need a database engine. PostgreSQL is recommended,
> because we're PostgreSQL fans, and MySQL, SQLite 3, and Oracle are
> also supported."
>
> And if you want to make it a relational database,
Err... I may totally misunderstand you here, but I've the strong
impression that you missed the fact that the database systems
mentionned above are all (so-called) relational dabatases.
bruno.des...@gmail.com
> I have a need for a database program. I downloaded the db2 from ibm,
> and reviewed some of the documentation.
>
> My question is, what is the easiest program for me to try to learn. I
> will be creating a database of about 25,000 records, it will be
> relational. I am a beginner Python programmer, and need a database
> solution that is easy to grasp. I played with sql,
> and found that very difficult, if not overly cumbersome.
The point is that so far, "relational database" really means "SQL
database". And believe me, trying to get away with a non-SQL database
only to avoid learning SQL is probably the worst possible move for
both your program and yourself.
> A database that could work with Django would be very interesting to
> look at as well..
The databases that the ORM part of Django can connect to are all SQL
databases.
> Any suggestions out there?
I can only second / third etc what everyone already told you : learn
SQL. And not only SQL, but also the theory that it builds upon (the
'relational model'), and the good practices wrt/ relational database
design. There's no shortage of good quality freely available
documentation on these topics, and you'll find help on quite a couple
of newsgroups / forums / whatever.
I'd strongly recommand you start without Django's ORM first, so you
get a chance to learn how it really works undercover. Else you might
end up doing things in a very inefficient way.
CM
You misunderstood me, but completely understandably. I meant that
a) the OP wanted to use Django, and so I was giving the word on the
only database engines that would work with that and b) the OP wanted
to use a relational database, and therefore would have to use SQL
despite not wanting to. But these two facts are completely connected,
and by leaving out that connection it seemed like those DBs weren't
relational. It would have been better for me to have said: "All of
these are relational databases, and, like any relational database
(which you want yours to be), they will require SQL." Sorry for the
confusion.
Gary Duzan
M.-A. Lemburg <m...@egenix.com> wrote:
>On 2008-04-07 15:30, Greg Lindstrom wrote:
>>
>> SQL is one of the areas I wish I had mastered (much) earlier in my career
>
>Fully agree :-)
>
>Interesting comments in a time where everyone seems to be obsessed
>with ORMs.
It seems to me that ORM can work if your database isn't too
complex and it is the only way your database is going to be accessed.
In our case, we have a messy legacy database (lots of tables,
triggers, stored procedures, etc., that nobody really understands)
with multiple processes hitting it, and so our efforts to integrate
Hibernate haven't been terribly smooth. In this environment the
hack seems to be to have Hibernate write to its own tables, then
have stored procedures sync them with the old tables. Not pretty.
Gary Duzan
Simon Brunning
> It seems to me that ORM can work if your database isn't too
> complex and it is the only way your database is going to be accessed.
I'm working on a big, complex system using an ORM at the moment -
http://gu.com. It's a Java/Hibernate/Spring system rather than
anything Python based, but the principle is the same. We find that the
ORM works great for 99% of our DB interaction, and saves a lot of
tedious fiddling around.
*But*, the 1% is crucial. Using an ORM doesn't mean you don't have to
understand what's going on underneath. When you need to hand craft a
performance critical query, or when you are chasing down a bug, you
need to know SQL, and know it well. C.F. The Law of Leaky Abstractions
- http://tinyurl.com/bmvn.
It's not either SQL or ORM. It's both. But SQL should come first.
--
Cheers,
Simon B.
si...@brunningonline.net
http://www.brunningonline.net/simon/blog/
GTalk: simon.brunning | MSN: small_values | Yahoo: smallvalues
D'Arcy J.M. Cain
CM <cmpy...@gmail.com> wrote:
> You misunderstood me, but completely understandably. I meant that
> a) the OP wanted to use Django, and so I was giving the word on the
> only database engines that would work with that and b) the OP wanted
> to use a relational database, and therefore would have to use SQL
While most database systems require SQL, the type of database and the
query language used are are not as tightly coupled as you imply. I did
quite a bit of work in Progres DB in a 4GL that was not SQL although
SQL was an optional extra. The original query language for PostgreSQL
and its predeccessor was QUEL, not SQL. There are other examples.
See http://en.wikipedia.org/wiki/SQL#Alternatives_to_SQL for some.
This is not to say that learning SQL is a bad idea. It is certainly
the de facto standard today.
--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
M.-A. Lemburg
While ORMs are nice if you want to get something done quickly,
I usually prefer to take the standard database abstraction layer
approach: it encapsulated all the database wisdom an application
needs, so you don't have to deal with these details at higher
levels in the applications, but still allows you to dive right
into the full feature set of whatever backend you are using.
In addition to having just one place to look for SQL statements,
it also provides the needed abstraction to be able to support multiple
different backends - by using a common base class and having one
subclass per supported database backend.
This straight-forward approach makes maintaining support for
multiple databases much easier and also allows us to work around
problems which you inevitably run into, e.g. missing support
for certain features in one backend, data type conversion needs
for another, etc.
Another problem I found with ORMs is error handling. Since most
of the database interaction happens behind the scenes, errors
can pop up in situations where you might not expect them in
your application. Again, the database abstraction layer provides
better control, since that's where you run the queries and deal
with the errors.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 09 2008)