Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Database, PDO, MySQLi, OOP, S...
June 4, 2007, 9:20 pm
rate this thread
connection. I code fast-running structural oriented CMS and I don't
know what I should do. I use mysql connection using mysql_*. I want
also to use SQLite.
Can you give me some advices?
1. PHP4 is still used. I want to be compatible.
2. There are various methods - MySQL, MySQLi, SQLite, PDO... I have
noticed that PDO and MySQLi will be pervasive only in the future. One
of paid servers doesn't support MySQLi because of its platform -
3. I have read some notes and articles so I have stated that PDO isn't
perfect and MySQLi and MySQL are better interfaces.
4. Is SQLite3 only accessed from PDO?
5. Does procedural MySQLi use objected mechanisms?
6. I have read that OOP uses more computational power of CPU and uses
more RAM. Is it true? The main aim of this CMS is SPEED and little RAM
using. I might only use OOP for database connection like PunBB.
7. If there would be MySQL_* support, should be other function also
procedural? If a function return an object, will be it his copy or
only a reference?
Why do I need other functions? If I want to get data to an array, I
don't want to type so much code - but only call 1 function, e.g.
The function would also add table's prefix to table name (as present).
Re: Database, PDO, MySQLi, OOP, S...
Is unstructured programming better then? ;) No, serious, anything you
can do with objects, you also can do with functions and "line-by-line
programming". The advantage of object orientation is mainly in its
structure. This structure will give you good chances for optimization,
if used well.
When using objects, you can just use inheritance and deal with a more
"abstract" database. When using functions, you'd probably want some
database functions that you pass a parameter saying which database (and
what type; you can probably use the get_resource_type function on the
connection) is used and act accordingly.
If the PHP developers just drop mysql_ support, I think there will be a
huge compatibility problem. But it is an external library, so you can
probably install it on future versions. I still use it, because mysqli
does not bring me any advantages, just the disadvantage that it is not
installed on quite a number of providers.
If you do it right, you can do a lot of optimization with objects. The
main thing here is "lazy computation": reading something in memory only
when you need it, and keeping it. This does use more memory, but saves a
lot of duplicate code (and duplicate running of code). Most procedural
or blind-panic code I have seen do not have any context to fall back on.
So it has to create any context where it is needed, bloating up a good
deal of code. But off course, it does not have to be this way.
Procedural code and object-oriented code have one thing in common: you
have to be good in programming. That said, Use the one you are familiar
with and do not be afraid to learn from other programming techniques and
You can use the mysql_ functions from within objects (which is what I
do). What the methods of such an object return is entirely up to you. I
did have a "record" object in the past, but I switched back to using
plain arrays for the rows.
Well, that is an advantage of using an object, isn't it? you construct
the object once with a prefix, and you can forget about it. It is then
the responsibility of that object to incorporate it in anything it does
to the database.
The real world is usually somewhat more difficult. You probably also
want to write to the database. And use more than one connection,
especially if you use transactions. Just imagine what happens to an
error log table in combination with a rollback in just one connection.