Posted by h3rald
Sat, 15 Sep 2007 19:10:00 GMT
In the last post of this series I tried to find a DRY solution to deal with tables storing “ancillary” data, i.e. names of user roles, predefined categories, page state names and other similar things.
I personally chose to put this kind of data to make my application more dynamic, although I could have decided to use ENUMs or simply ordinary varchar fields—that would have been easier, but less flexible. For now, I’m sticking with my original choice.
The data in these tables is kind of a prerequisite for the application to run: I must be able to have a status to assign to a user when creating it, and the same applies to roles. Sure, I could spend 20 minutes populating these tables manually, but it would be nice if there was a less tedious way, wouldn’t it?
There is indeed. The inspiration came from a technique described in the book (which I highly recommend) Agile Web Development With Rails, in which the author outlines how it would be possible to use Rails’ fixtures and migrations to load data in the database automatically from YAML files.
All you have to do is create a migration to load the specified YAML files and you’re all set.
I wanted to take a little step further, allowing the migration to load data from all YAML files in a specific directory, automatically.
Read more...
Posted in Blog | Tags databases, Rails, ruby | 4 comments | no trackbacks
Posted by h3rald
Sat, 14 Jul 2007 17:27:00 GMT
This week I attended a course for work on how to Implement Databases with Microsoft SQL Server 2005. An interesting course indeed, which made me realize how feature-rich Bill’s product is, compared to the Open Source alternatives like MySQL. It also made me realize how nice it is to implement database-related logic (read: Models) using a proper programming language rather than using triggers, stored procedures, functions and other goodies offered by Transact-SQL.
It’s all a matter of taste and of necessities: using MS SQL Server for one of my website is simply not going to happen anytime soon, and I’m more than happy to have a database which can be used just as a database and a programming language (Ruby, in this case) which can do wonders, rather than a procedural-only surrogate.
Anyhow, back to our weekly series. After creating a concept map, it’s time of get real and try to figure out a database architecture.
Read more...
Posted in Blog | Tags databases, Rails | no comments | no trackbacks
Posted by Fabio Cevasco
Mon, 17 Apr 2006 13:30:00 GMT
One of the most recurring questions on CakePHP User Group is probably “Does Cake support X database?”. Sure, most of us tend to use just MySQL for our websites and applications, but in certain situations some more exotic database support makes the difference. A partial answer to the question above could be “Yes, probably, at least partially”: CakePHP offers support for some database “natively” (i.e. Cake folks made some ad hoc database drivers), others through either ADOdb or PEAR::DB.
CakePHP seems to use a multiple level database abstraction: in other words, popular abstraction layers like ADOdb or PEAR::DB have been wrapped in a “driver” which basically extends the DboSource class (which is the most high level database abstraction). Some people don’t like the idea, because this means that the could be some performance issues, for one, and also that inevitably not all features offered by either ADOdb or PEAR::DB are used. In my very, very, very modest opinion (I’m not an expert on this matter), this solution focus on achieving good database compatibility leaving the doors open for further tinkering, if needed.
Having said this, yes, the possibilities are good that your favorite database is supported by CakePHP, more or less. Of course, as repeatedly pointed out by some CakePHP core developers, Cake dev team didn’t and is not going to test every database with Cake, using either of the two abstraction layers, but users are more than welcome to do so.
Let’s now have a look at what is known to work with Cake:
MySQL works fine, and is currently recommended as preferred database solution. What about MySQLi? Well, thanks to mappleJoe there’s a (PHP5 only!) driver ready to be used.
PostgreSQL’s support is continuously improving. Something may work, something may not: the good news is that the folks who are using it are sharing their thoughts with the rest of us.
SQLite is supported natively, or so it seems… what about the newest SQLite3? Yes, probably: there’s a quick howto on ThompsonLife.net to make it work through the dbo_pear driver.
Access works through the ADOdb driver, as reported in CakePHP wiki (thanks ivanp).
FileMaker is getting there: things aren’t that easy, but bdb is doing all his best to make it work, good luck!
Neil Fincham was also trying to develop a custom driver to support Pervasive through a unixODBC driver. Best of luck!
For other databases, check ADOdb’s list of supported databases and use the dbo-adodb driver, or use PEAR::DB (for fbsql, ibase, informix, msql, mssql, mysql, mysqli, oci8, odbc, pgsql,sqlite and sybase) using the dbo-pear driver.
Posted in Blog | Tags CakePHP, databases | no comments | no trackbacks
Posted by Fabio Cevasco
Tue, 28 Feb 2006 20:50:00 GMT
MySQL[1] is a great database solution. Literally millions of people who use it can tell you that it is a well-performing, feature-rich database solution for almost any size project: it is low-cost (often free), and available on the majority of webservers all over the world.
Read more...
Posted in Articles | Tags databases, review | no comments | no trackbacks
