Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a homebrew MVC framework that I have been using for a while, and it has been working great, but I am planning an upgrade to it for its ORM classes. So far, it only supports SQL databases by creating statements dependent on what function is being called. The ORM class includes field structure and validation, computed fields, indices and joined classes (for associations, 1-1, 1-*, *-1 and *-*), and that provides enough functionality for selecting any data and fetching associated rows in the database.

But I would like to extend it to support XML, LDAP and NoSQL databases (i.e. MongoDB). My ideas for implementing this would be to modify the functions within the ORM class to interact with a custom driver (for each database type) in a common format. Unfortunately, I haven't had enough experience with using these other formats enough to adequately design an interface class that could be used by the ORM for any type.

So, are there any universal database drivers that would support all of these database types so I can learn by example?

The current interface I am working by is:

interface DBDriver {
  function connect($host, $un, $pw, $persist = false);
  function disconnect();
  function selectDB($db);
  function charset($charset);
  function insert($table, $values);
  function select($table, $fields, $joins, $where, $group, $having, $order, $limit);
  function update($table, $where, $values, $where, $order, $limit);
  function delete($table, $where, $order, $limit);
  function transactionBegin();
  function transactionCommit();
  function transactionRollback();
}

But I am concerned that although this will provide enough for creating SQL statements, it might not be sufficient, or perhaps even overkill for other methods such as XML or NoSQL.

share|improve this question
2  
Universal database drivers sound like a really bad idea. You have to give up supporting certain features and are forced expose other things to support other features. Why not design indivual interfaces and implement specific functions for those backends. –  Ramhound Apr 23 '13 at 16:11
    
ideally, that would be perfect, but that would require writing an ORM library extension for each type. But as the basis of each database follows a similar principle (providing methods to Create, Read, Update and Delete rows), would it be such a bad idea to create a common interface for all of them together? –  cgoddard Apr 23 '13 at 16:23
    
Can you not inherit multiple interfaces? Create a base Read interface that all specific read interfaces inerheits. Your concern is real and is the reason it hasn't be done before. –  Ramhound Apr 23 '13 at 16:36
    
I am in the process of designing an interface, but I am trying to design a method that I could use to access the table rows in a constant format, regardless of the database the row is stored in. The dream is to have an orm that stores rows of one type, and if one day it changed from being stored in a MySQL table to being stored in a MongoDB collection, then there will be no changes needed to be made to any code that interacts with it to maintain its functionality –  cgoddard Apr 23 '13 at 16:48

1 Answer 1

It would be so abstract that it wouldn't do anything useful (analysis paralysis / abstraction inaction). The best thing to do would be to define interfaces for CRUD/BREAD/etc and implement them as they are needed. If you're using PHP 5.4 you can take advantage of traits so you can cook up drivers piecemeal for shared behavior.

interface Create { }
interface Read { }
interface Update { }
interface Delete { }
interface Browse { }
interface Edit { }
interface Add { }
interface CRUD extends Create, Read, Update, Delete { }
interface BREAD extends Browse, Read, Edit, Add, Delete { }
interface Transactional { }
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.