I'm interested in learning more about design practices in PHP for Database Abstraction & Factory methods. For background, my site is a common-interest social networking community currently in beta mode.
Currently, I've started moving my old code for object retrieval to factory methods. However, I do feel like I'm limiting myself by keeping a lot of SQL table names and structure separated in each function/method.
Questions:
Is there a reason to use PDO (or similar) if I dont anticipate
switching databases?
Can PDO interface with the MySqli prepared statements I
currently use?
Will it help me separate table names from each method? (If no, what
other design patterns might I want
to research?)
Will it slow down my site once I have a significantly large member base?
Nettuts recently had an article on some of the benefits to using PDO.
As for your question regarding abstraction, you might look into Object Relational Mapping (ORM) which lets you access database records the same way you would native php objects. Most of my experience has been with the Kohana framework, and I like how their ORM works, but many of the popular php frameworks should have good examples of database abstraction methods. I find that reading where someone else did it the "right" way helps me out.
I would like to second Rookwood on looking at ORM. I have had good experciences with Doctrine. Building something yourself would be a waste of your time in moste cases.
I would recommend using PEAR or PDO.. why?
1) It's tested and used by tens of thousands of programmers. If you need another programmer to help you, there is a good chance they know PDO. There is basically zero chance they will know your API.
2) You don't think you will change databases.... BUT, what if a version change or something like that happens that forces you to migrate?
Related
I have been using ezSQL for the last few years but feel it is outdated. Though I like the simplicity and I like the file based caching ability with json, for small result sets that is.
So starting a new project I was looking for suggestions on a better mysql class for php. I know the db will only be mysql so portability is not a requirement. I read about mysqli extension, pdo etc but just dont know which one would be best for my situation. The site does a lot more reads than writes, though there are times where there are a lot of writes in the admin tool to the db. I looked at doctrine but dont know if that is too "bloated" for what I need. Hopefully this isnt to vague. Any suggestions?
EDIT
The site isnt small, I would consider it a high traffic site with a lot of db queries.
What don't you like about ezSQL? I often wish there was something like it for other protocols/languages I encounter. Every syntax should be written like ezSQL, in my opinion.. It describes the operation to be performed, in as few words as is possible, in the clearest and most logical order. Do you actually have performance problems, or are you just worried that something better has come along? I agree that ezSQL is rarely mentioned, but I have yet to find anything that matches it's simplicity, conciseness, and function...
From what I know of ezSQL (via it's wordpress pendant) I would consider Doctrine as well as too much for the moment because it's a complete data mapper for the database whereas you might be more looking to how to move away from your recent use of ezSQL which I think is a good idea.
Bascially you might be interested in a data-access abstraction layer. That could be PDO as it's build in into PHP. Even if you don't need to change the database server, it will give you defined interfaces how to query and access the data.
As you build the site from scratch, I can suggest you consider using some lightweight framework. A good introduction in my eyes is When Flat PHP meets Symfony which shows how a webapp can generally benefit from patterns and a flexible design.
From experience:
Doctrine - very easy to use I love doctrine query language - I never had to do initial setup though so im not sure how hard it is. It has very good community and lots of tutorials.
Propel - used for a bit. Does the job, very similar to doctrine. However, the documentation is very crap and community is very slack. I found that when I didn't know something it was quite hard to find an answer and often I had to post on Google forums.
Note: If you are starting from scratch you might want to look at some of the frameworks such as symfony+doctrine is a good combination, makes development a lot easier.
Links:
- http://www.doctrine-project.org/
- http://www.propelorm.org/
I am building a site that requires a lot of MySQL inserts and lookups from different tables in a (hopefully) secure part of the site. I want to use an abstraction layer for the whole process. Should I use a PHP framework (like Zend or CakePHP) for this, or just use a simple library (like Crystal or Doctrine)?
I would also like to make sure that the DB inserts are done in a relatively secure part of the site (though not SSL). Currently, I am using the method outlined here (MD5 encryption and random challenge string), but maybe some of the frameworks come with similar functionality that would simplify the process?
What I'm trying to implement: a table of forms filled out with DB values. If you change a value or add a new row, pressing "save" will update or insert DB rows. I'm sure this has been done before, so I wouldn't want to reinvent the wheel.
Most PHP backends have secure access to a private database. Normally, there's little difficulty to keeping the database secure, mostly by not making it reachable directly. That way the security of access depends on the inability for anyone to tamper with the PHP code, and not any software security scheme.
I would recomend Symfony Framework for this. There is a great online tutorial on this at Practical Symfony.The Framework's Form class handles most of the security for you. It also has a nice login plugin to make the application secure.
Unless by Data Abstraction you mean an implementation of a Data Access Patterns like ActiveRecord or Table Data Gateway or something ORMish (in both cases you should update your question accordingly then), you don't need a framework, because PHP has a DB abstraction layer with PDO.
It sounds like you are really asking two different questions. One being should I use a framework (Zend, Symfony, Cake, etc) for the development of a website? The other being whether or not to use something along the lines of an ORM (Doctrine, Propel, etc)?
The answer to the first one is a resounding "yes". Frameworks are designed to keep you from having to reinvent the wheel for common/basic functionality. The time you spend learning how to (correctly) use a framework will payoff greatly in the long run. You'll eventually be much more productive that "rolling your own". Not to mention you'll gain a community of people who have likely been through similar situations and overcome issues similar to what you will face (that in and of itself could be the best reason to use a framework). I'm not going to suggest a particular framework since they all have strengths and weaknesses and is another topic in and of itself (however, I do use and prefer Zend Framework but don't let that influence your decision).
Concerning whether or not to use an ORM is a slightly more difficult question. I've recently began to work with them more and in general I would recommend them but it all boils down to using the right tool for the right job. They solve some specific problems very well, others not so much. However, since you specifically mention security I'll quickly address that. I don't think that a ORM inherently "increases security", however it can force you into making better decisions. That said, bad coding and bad coding practices will result in security issues no matter what technology/framework you are using.
Hope that helps!
There are two things that seem to be popular nowadays and I was wondering what are the pros and cons of using something like this: http://codeigniter.com/user_guide/database/active_record.html ?
Another thing is ORM (Doctrine for instance). What are the benefits of using these?
ActiveRecord is a pattern common in ORMs. Doctrine is an ORM which uses an ActiveRecord'ish style.
Some benefits of using tools like Doctrine:
Database independence: The code should be easy to port to different DBs. For example, I often test using SQLite and use MySQL or Postgre in production with no changes in code.
They reduce the amount of code you have to write: A large part of application code deals with communicating with the database. An ORM takes care of most of that, so you can concentrate on writing the actual app.
Of course, they don't come without disadvantages:
Doctrine is heavy so it is slower than using straight SQL
ORMs can be complex, adding some weight to what you have to learn, and they can sometimes be difficult to understand for inexperienced programmers
You can take a look at these questions though they're not exactly PHP specific:
Are there good reasons not to use an ORM?
Using an ORM or plain SQL?
I tried to keep it light-weight and understandable. Even comes with it's own Mootools based Class Generator :)
http://www.schizofreend.nl/Pork.dbObject/
check it out :)
In PHP, what is the best practice for laying out the responsibilities of a Db Abstraction Layer?
Is OOP a good idea in terms of performance? How much should be generic object code, and how much should be very specific functions?
There are already some great solutions for this. A DAL is not a simple thing, especially since so many security concerns are involved. I would suggest checking out PDO and MySQLi. Even if you write a wrapper class for one of them, the heavy lifting will be done for you in a robust and secure way.
In most applications I have written, there are generally two different types of data access. One is for transactional operations: retrieving specific objects from the datastore, modifying them and saving them back. I've found a solid ORM to be the best solution here. Don't try writing your own (as interesting as it might be.)
The other common type of data access is for reporting. ORMs aren't the best solution here, which is why I usually go with a scheme that uses custom SQL queries. Plain ol' PDO works well here. You can create a special value object just for that report and have the PDO query fetch the values into the object. Reports need to be fast and building them using an ORM layer is usually just too slow and cumbersome.
I have inherited an old crusty PHP application, and I'd like to refactor it into something a little nicer to deal with, but in a gradual manner. In perl's CPAN, there is a series of classes around Class::DBI that allow you to use database rows as the basis for objects in your code, with the library generating accessor methods etc as appropriate, but also allowing you to add additional methods.
Does anyone know of something like this for PHP? Especially something that doesn't require wholesale adoption of a "framework"... bonus points if it works in PHP4 too, but to be honest, I'd love to have another reason to ditch that. :-)
It's now defunct but phpdbi is possibly worth a look. If you're willing to let go of some of your caveats (the framework one), I've found that Doctrine is a pretty neat way of accessing DBs in PHP. Worth investigating anyway.
Class::DBI is an ORM (Object Relational Mapper) for perl. Searching for "PHP ORM" on google gives some good results, including Doctrin, which I've had good luck with. I'd start there and work your way up.
I'm trying to get more feedback on my own projects, so I'll suggest my take on ORM: ORMer
Usage examples are here
You can phase it in, it doesn't require you to adopt MVC, and it requires very little setup.
The right thing to is to access the database via an abstraction layer in a way such if you change your RDBMS or how you implemented that access, you only have to modify this layer while all the rest of your application remains untouched.
To do this, to free your application from knowing how to deal with the database, your abstraction layer for DB access must be implemented by a framework such as ADODB.
All the files related to this layer must be located in a sub directory:
/ado
In this directories you'll put all of your .php.inc files which contains general methods to access the database.
How about MDB2 from pear?
It provides a common API for all
supported RDBMS. The main difference
to most other DB abstraction packages
is that MDB2 goes much further to
ensure portability.
Btw: #GaryF what are those strange title attributes your links have ? Did you add them or are they added by SO ?