Abstraction Layers?

[Arty Ziff]

Currently, I'm using MySQL. and I don't see transitioning to something else as very likly. But if we did, it would be PostgreSQL.

 

In any case...

 

What is the current "group-think" on abstraction layers? For non-trivial applications?

 

Any favorites?

[fenway]

Well, you must have _some_ sort of DB layer already, correct?

[ebmigue]

One way of providing an "abstraction layer" between databases - relational databases, for that matter - is to have a library that implements the Relational Algebra.

 

I would recommend re (http://www.reetudes.com).

 

Though currently, the 'driver'  for PostgreSQL is not yet implemented. But it would be relatively trivial to do it yourself however, IMO.

 

 

 

[fenway]

One way of providing an "abstraction layer" between databases - relational databases, for that matter - is to have a library that implements the Relational Algebra.

 

I would recommend re (http://www.reetudes.com).

 

Though currently, the 'driver'  for PostgreSQL is not yet implemented. But it would be relatively trivial to do it yourself however, IMO.

You've already been warned once for not disclosing that you're advertising your own personal framework -- careful now.  Caveat lector.

 

On a more relevant note, are you seriously answering the OP's question for a DB-independent solution by suggestion one that doesn't even support a second DB?

[ebmigue]

You've already been warned once for not disclosing that you're advertising your own personal framework -- careful now.  Caveat lector.

Well, I have my reasons for not specfying that is a personal framework. AFAIK, the original admin. that warned me accepted such reasons.

 

On a more relevant note, are you seriously answering the OP's question for a DB-independent solution by suggestion one that doesn't even support a second DB?

What do you mean "doesn't even support a second DB?"

 

Well, actually, re only has two "drivers" for existing DBMS: mysql and mssql. If he wants to use PostgreSQL DBMS, he _can_ write his own "driver". I see no problem in that.

[fenway]

Your humility aside, you're still pushing your own wares -- if you're proud of your work, there's no reason not to own up to it.

 

Once again, the OP is looking for a solution, not more work to do.  They asked for something that *does* support PostgreSQL, and you've offered up something that *might* it -- in theory, if you like -- and hence I don't think that's of much help.

 

They could have just as easily added additional DB support to any existing framework -- so why push that one in particular?  I'm baffled.

 

He *can* also building with own DB -- but he's not going to do that, either.

[ebmigue]

Your humility aside, you're still pushing your own wares -- if you're proud of your work, there's no reason not to own up to it.

Alright. Next time, I will.

 

He said:

Currently, I'm using MySQL. and I don't see transitioning to something else as very likly. But if we did, it would be PostgreSQL.

 

In any case...

 

What is the current "group-think" on abstraction layers? For non-trivial applications?

 

Any favorites?

Why you were able to infer that "the OP is looking for a solution, not more work to do.  They asked for something that *does* support PostgreSQL," baffles me.

 

I suggested re, because they can still have time to write their own driver "if they did" migrate.

 

A suggestion and a working product might be solutions.

 

They could have just as easily added additional DB support to any existing framework -- so why push that one in particular?  I'm baffled.

Because I think that existing frameworks are not "that abstract."

[fenway]

I was able to infer that because that's the nature of these forums -- again, after 14K+ posts, let's call it a "working theory".

 

The OP was asking for "favourites" -- implying one that actually worked with PostgreSQL -- and was asking for experiences pertaining to such solutions.

 

Besides, the entire point of such frameworks is precisely to provide an abstract level of representation -- granted, not all at the DB level -- and if you think that your framework is better than everyone else's, that's fine -- but again, not exactly an unbiased opinion, especially without full disclosure.

[ebmigue]

I was able to infer that because that's the nature of these forums -- again, after 14K+ posts, let's call it a "working theory".

Are you now bullying me and using your authority, because of your reputation here?

Please, I don't want to get personal. let's stick with the posts, the content of posts.

 

The OP was asking for "favourites" -- implying one that actually worked with PostgreSQL -- and was asking for experiences pertaining to such solutions.

Yes. In my experience, he can create his own concrete solution. The solution I suggested was an idea. Are you telling me giving ideas are not anymore allowed here?

 

Besides, the entire point of such frameworks is precisely to provide an abstract level of representation -- granted, not all at the DB level -- and if you think that your framework is better than everyone else's, that's fine -- but again, not exactly an unbiased opinion, especially without full disclosure.

 

I don't think that it's better of them all.

 

Just a suggestion to the OP. Just that.

 

Some framework may not be "that abstract", but of course, abstraction is not the only criteria for being "better" right?

 

But the general idea of using relational algebra, _might_ be a good start of abstraction. That was the whole idea of my suggestion to him.

 

Again I am sorry if I didn't fully disclose it. On the next opportunity, I will do so.

[fenway]

You asked me how I infer things -- I told you "through experience" -- that has nothing to do with authority.  Sounds like you're the one taking it personally.

 

You can give any one ideas -- and if that's how you interpreted the OP's request, then so be it.

[Arty Ziff]

Well, you must have _some_ sort of DB layer already, correct?

This little discussion with / about user:ebmigue is interesting and all that, but has essentially HIJACKED my thread which is asking a question.

 

Sure, I do use an "abstraction layer" of sorts in that I've written a class that handles the actual php DB commands - information about what I need to query is passed to the class, and results are passed back.

 

But it's "homegrown" and limited, and I want more. I'm not interested in reinventing the wheel.

 

I'm thinking of ADOdb, and I know there are competing libraries.

 

I'm assuming people here have personal opinions about the completeness, design, and usability of ADOdb and similar libraries?

 

User:ebmigue's project looks very interesting, and I will look at it because it looks interesting, but it's NOT what I'm looking for today...

[ebmigue]

This little discussion with / about user:ebmigue is interesting and all that, but has essentially HIJACKED my thread which is asking a question.

Sorry about that, if I took a part in it.

 

I'm assuming people here have personal opinions about the completeness, design, and usability of ADOdb and similar libraries?

Yes, I have an opinion.

 

 

I assume that you want your code to still work, even if the underlying DB is changed from say MySQL to PostGre. That you do NOT want to modify your source code when you migrate from one DB to another? Is that right?

 

If "no" stop reading. If "yes" I will explain my suggestion to you.

 

So to answer your question: "Abstraction Layers?"

My answer: Use a common language and data construct. Adopt what the pioneers did 40 years ago.

 

You see, the main reasoning is this:

 

The original intention of the pioneers in DBMS is to create an abstract programming language that is suited

for data manipulation.

 

Their idea was that instead of contenting ourselves w/ the usual data types (INTEGERS, STRINGS), why not

add a data type that is suited for manipulating data? E.F. Codd then introduced the RELATION data type.

 

Further, additional operators/functions are then introduced to manipulate values (including values in a variable reference) of the type RELATION: JOIN, UNION, MINUS, etc.

 

Analogously, if there is a "+" operator for INTEGERS, there is a UNION operator for RELATIONs, and so on.

 

Thus the relational algebra was developed (the relation data type plus the operators).

 

The nice consequence of having an abstract language of manipulating data is that users/programmers

are rid of technical details that are involved when manipulating data. Data manipulation then is practically "abstracted".

 

For instance, if you want to compute the tuples/rows in relation variable (relvar/table) A

that are not in relvar/table B, you simply:

A MINUS B 

(Exercise for the reader: implement this in SQL)

 

You need not worry on indexes, the kind of loop to use, the source of such data, etc, etc.

 

(

Of course in practice you will concern yourself w/ performance; but that would be in administration/maintenance part; not on the actual product development and modelling.

In practice, too, the DBMS optimizer will automatically help the programmer in optimizing his/her code

In theory, if you want to improve performance, there is no need to adjust and recompile your source code!

Simply adjust the settings "under the hood" so to speak, w/c is the Physical Layer of the DBMS

).

 

So, how did they do it in the field of relational DBMS 40 years ago?

 

They created an abstract language w/c is now usually referred as Relational Algebra.

 

All you have to do is to implement such abstract language, say, in PHP (or in any language), and you will

have an abstraction layer between/across databases or sources of data (say, one of the web services by Google)

 

...I will look at it because it looks interesting, but it's NOT what I'm looking for today...

I posted this reply for future for your future reference..

 

Thank you and hope it helps.

[ignace]

If you already have a class say Database, you can create a postgresql class that extends your Database object and overrides all methods.

 

class Database {/*mysql/mssql*/}

class PostGreSQL extends Database {/*override all methods of Database*/}

 

Better would be if you made Database an interface and then create a MySQL, MSSQL, and PostGreSQL class. It wouldn't take you more than just changing the original

 

$db = new MySQL(..);

 

To the new:

 

$db = new PostGreSQL(..);

 

If you are in to Design Patterns I suggest using a Factory to get the DB driver.