Page 2 of 2

Re: OOP and SQL

Posted: Tue Mar 28, 2006 5:10 am
by timvw
Hockey wrote: 1) HTML does not belong inside a class...thats the worst example of OOP...
I'm aware that there are many projects where static html with embedded code will lead to a better/faster solution for them.

But why can't a set of classes model a HTML document and it's elements?
And why would that model be the worst example of OOP?
Hockey wrote: If I want to use your class, who says I want the header your class outputs? HTML is better left for template engines...
Who says you have to use the default method to generate a header? Who says my class would output anything?
Why is HTML better left for template engines?
Why can't a template engine be OOP?
Hockey wrote: 2) And thats cool, but again it forces me into using it's database abstraction layer doesn't it? What if I want to use AdoDB or my own???
The consequence of writing OO code is that most of the times you develop several layers simply to allow yoru code to flexible and reusabe.

And yes, hibernate uses a layer for it's dialects and it uses a database-access layer, being the (more or less) only standard for Java, JDBC.
Hockey wrote: For me, reusability is "everything" when writting an class...if I can't reuse the class exactly as is in a later project I might as well save myself the time of writing extra class syntax (I'm that lazy yes) and proceed to writing fast efficient SQL functions instead of member functions.
So you are trying to say that member functions can't be fast efficient SQL member functions?
Hockey wrote: If you have CPerson class which maps to your very own database structure, it's very likely both the schema and your object properties, methods, etc will change in your next project...if you add an age field to your schema, you need to update your class...which is NOT reusable in the pure OOP sense of the word.
What is the pure OOP sense of reusable then?
The way i see it you can easily inherit from that CPerson and add a age property.

If you had actually looked at Hibernate you would have seen that it's perfectly possible for the scheme generator to take care of this too.

Re: OOP and SQL

Posted: Tue Mar 28, 2006 5:31 am
by timvw
Hockey wrote: It's not reusable like a class should be.
Could you explain how a reusable class should be like?
Hockey wrote: I use a Smarty style template engine and like all my forms done by a designer who makes them look awesome.
I agree that there are other approaches to generate HTML, but i thought this discussion was about OOP and resuability so i don't see the relevancy here.
Hockey wrote: Ideally (Although current frameworks, template engines, etc don't offer 100% satisfaction) you should always strive for HTML/CONTENT seperation as well as PHP/HTML seperation.
Why should i strive for that? I know many projects where this would be pure overkill.
Hockey wrote: Problem is, what if I want more control over the output of my FORM html? Even if FORM generators had an API for manipulating every last visiual aspect of a FORM output, the amount of code it would require in PHP would be more than what it's worth - it would be easier to use plain HTML.

Why wouldn't you be able to change the behaviour of the HTML classes?
If you like to edit all your smarty templates to achieve the same result, be my guest. (As you can read above, i agree that there are indeed projects where this is the best way to go)
Hockey wrote: Besides HTML does what it does and PHP does what it does...hence the introduction of template engines.
Well, this is exactly the reason why PHP exists today: To embed some code in static html.
Hockey wrote: I didn't mean dismal in the sense that there is no performance hit, but just wrapping a couple functions into a classes namespace doesn't cause "much" of a performance hit...when you start deriving classes, etc and using composition like mad which are also objects, then classes become a potetial performance problem. But I dought that just simple wrappers - which I imagine MOST database classes are incur much of a performance hit.
I agree, there are problems with the current implementation of PHP and i agree, but i don't see a conceptual problem.

I agree that it's time to clean up the mess those dbms vendors have made.
Hockey wrote: Nothing wrong with it, just not really needed, especially in a performance-centric or should I say performance-concerned environment like a shared host or web server of any kind. I disagree with procedural programming making for a "less clean design".
I've never said that procedural programming results in a "less clean design". I don't even like to use the term because it's hard to define it well.
Hockey wrote: Thats not the purpose of OOP IMHO anyways. OOP helps prevent namespace collisions, so in that sense it's cleaner I guess - if thats what you meant. But it's just as easy to prefix a codename or namespace to a global function and likely avoid namespace collisions as well. :)
As you said, classes help prevent namespace collisions, but that's only a side-effect of OOP.
Hockey wrote: class CPerson{
function insert(){}
function update(){}
function remove(){}
function removeExpired(){}

function isMale(){}
}
I don't like that (activerecord) approach because it mixes the application domain with the implementation.
I don't know many persons that can CRUD themselves ;)
Hockey wrote:

Code: Select all

function getAge(){ return mysql_query('SELECT age FROM persons WHERE pkid = 2'); }
Not really my thing either, because i would have to write to much mysql myself.
I'd prefer to:

Code: Select all

<?php
$query = new SQLQuery('mysql');
$query->SetSelect('age');
$query->SetFrom('persons');
$query->SetWhere(array('pkid' => 2));

mysql_query($query->GiveQuery());
?>
Hockey wrote: This way you can optimize SQL queries individually as required, as opposed to having a generic Load() or Save() method serialize your entire object. If you did use this approach however, I suppose classes would make more sense in the cleaner design sense, yes I agree :)
You really should have a look at Hibernate :) It doesn't serialize an entire object at all (unless you'd ask it to do so)

Posted: Tue Mar 28, 2006 7:42 am
by John Cartwright
Hockey wrote: 1) HTML does not belong inside a class...thats the worst example of OOP...
Its not neccesarily a bad idea, but I generally avoid it. Although, helper classes to generate things such as forms, or elements are find perfectly acceptable -- look at the Zend Framework.

Posted: Tue Mar 28, 2006 12:44 pm
by timvw
Gambler wrote: Now, you need to write another script that displays all titles for today, plus prefaces, plus authors' names from another table. Can you use previous query and programmatically "add" new functionality on to it? No. You need to copy and paste.
I think i get what you're trying to say. SQL itself was never meant to be reusable, it was meant to be a language to query an SQL dbms. Does that mean you can't reuse the code that generates the actual SQL? I sure you can...

Btw, how could you make a similar change to your smarty templates? (The solution with HTML classes would be similar to the SQL example below. Should we call it a pattern?)

Code: Select all

<?php
class BarManager {
  function GetSomeBar() {
      $sqlgenerator = new SQLGenerator();
      $sqlgenerator->setSelect('*');
      $sqlgenerator->setFrom('bartable');
      return $sqlgenerator;
  }
}
    
class FancyBarManager {
  function getFanyBar() {
    $sqlgenerator = $this->GetSomeBar();
    $sqlgenerator->setSelect('fancy stuff');
    ..
  }
}
?>
Gambler wrote: With SQL, you can't easily break the problem into smaller parts and keep reasonable efficiency at the same time. Complex SQL is hard to generate and queries take too much time to be issued by hundreds inside a loop. That's why it's hard to reuse and fit into hardcore OOP applications.
I really don't get what you're trying to say here? As i've already said, instead of hardcoding something (SQL in this case) make your generic enough so you can generate it instead. That is what i consider reuse. Is the use of OO code limited due to the fact that it has to talk with a SQL dbms? I really don't think so.
Gambler wrote: Plus, there are other ways of dealing with data, which are simply better for things I code daily.
I've already agreed with the statement that an SQL dbms far from optimal.

Gambler wrote: As for the relational data model, I don't like many things about it. One, it encourages query paradigm.
What is "query paradigm"?
Gambler wrote: Two, it is not as flexible as data storage could be.
It's not meant to be a solution for data storage. It's meant to be a model for data.
Gambler wrote: Three, it's too abstract and complex.
I admit that it isn't easy.
Gambler wrote: During our last conversation you dismissed a couple of my points as “mere implementation details”. However, I work with implementations, so those details matter, a lot. There are things like deployment and maintenance. Relational data model complicates both, since you need to to create schema in the beginning and change it afterwards.
I dismissed them as implementation details, because your statements addressed SQL dbms (a flawed implementation of a dbms based on the relational model) and not the relational model itself.

Re: OOP and SQL

Posted: Tue Mar 28, 2006 12:47 pm
by alex.barylski
timvw wrote:
Hockey wrote: 1) HTML does not belong inside a class...thats the worst example of OOP...
I'm aware that there are many projects where static html with embedded code will lead to a better/faster solution for them.

But why can't a set of classes model a HTML document and it's elements?
And why would that model be the worst example of OOP?

Hockey wrote: If I want to use your class, who says I want the header your class outputs? HTML is better left for template engines...
Who says you have to use the default method to generate a header? Who says my class would output anything?
Why is HTML better left for template engines?
Why can't a template engine be OOP?
Hockey wrote: 2) And thats cool, but again it forces me into using it's database abstraction layer doesn't it? What if I want to use AdoDB or my own???
The consequence of writing OO code is that most of the times you develop several layers simply to allow yoru code to flexible and reusabe.

And yes, hibernate uses a layer for it's dialects and it uses a database-access layer, being the (more or less) only standard for Java, JDBC.
Hockey wrote: For me, reusability is "everything" when writting an class...if I can't reuse the class exactly as is in a later project I might as well save myself the time of writing extra class syntax (I'm that lazy yes) and proceed to writing fast efficient SQL functions instead of member functions.
So you are trying to say that member functions can't be fast efficient SQL member functions?
Hockey wrote: If you have CPerson class which maps to your very own database structure, it's very likely both the schema and your object properties, methods, etc will change in your next project...if you add an age field to your schema, you need to update your class...which is NOT reusable in the pure OOP sense of the word.
What is the pure OOP sense of reusable then?
The way i see it you can easily inherit from that CPerson and add a age property.

If you had actually looked at Hibernate you would have seen that it's perfectly possible for the scheme generator to take care of this too.
1) Not saying you can't :) Just that you shouldn't IMHO :)

I never said classes shouldn't model an HTML document and it's elements...in fact there is a well known class that does just that, it's called DOM ;)

But a DOM is, whats the word, an abstraction of a HTML document, there is no actual HTML code stored in a DOM, but rather a structured list of nodes which represent HTML tags.

That is an example of a class being reusable.

I guess what I'm trying to say, is embedded HTML in a class fixes that class strictly to your project, cuz for one wouldn't use it!

However a good example of a class like a DOM class (assuming technically it's up to par, bug free, compliant API, etc) I would use if nessecary.

Can you give any arguments why you wouldn't use a DOM class if needed (outside of it's code bloat, etc)? I think you'd be hard pressed to find any, because it's a great example of OOP.
Who says you have to use the default method to generate a header? Who says my class would output anything?
Why is HTML better left for template engines?
Why can't a template engine be OOP?
Show me an example of how you would use HTML in a class, I think one of us is missing something here :?

Why would your class contain any HTML (whose whole purpose is to render into visual elements on screen) not output anything? :P

Again I need an example of what your saying...

HTML is better left for a template engine, for the same reason parsing is better left for EBNF that hand coded. The same reason we use SQL instead of reading a file directly and executing hand coded queries on arrays. The same reason we use HTML instead of an element API:

Code: Select all

$obj = new CTableElement();
$obj->setAttribute('width', '100%');
Imagine coding an entire HTML document this way? It's tedious and hard on the eyes.
So you are trying to say that member functions can't be fast efficient SQL member functions?
Not even close, I understand the internals of how OOP works compared to procedural code, so I know first hand that a function call is only slightly faster than a class method call. With the exception of dereferencing the 'this' pointer, I would say there pretty much equivelant. :)
What is the pure OOP sense of reusable then?
The way i see it you can easily inherit from that CPerson and add a age property.

If you had actually looked at Hibernate you would have seen that it's perfectly possible for the scheme generator to take care of this too.
Yes you can, but using straight SQL without any of these mapper frameworks (Hibernate??) it would require alot of work...

I'll have to look into this Hibernate...but first I have to figure out Active Record :)

Cheers :)

Posted: Tue Mar 28, 2006 2:57 pm
by Gambler
Here is a very rough PHP4 pseudo-code example, but hopefully you get the idea that all the database access is encapsulate within the Gateway.
I understand the general idea, but how would you handle inter-table relations? (Like using user id to get user name for each article.)

Posted: Tue Mar 28, 2006 3:33 pm
by Christopher
Gambler wrote:
Here is a very rough PHP4 pseudo-code example, but hopefully you get the idea that all the database access is encapsulate within the Gateway.
I understand the general idea, but how would you handle inter-table relations? (Like using user id to get user name for each article.)
Because the Gateway encapsulates all of the SQL you just provide a finder method that abastacts the query.

Code: Select all

function findArticleHeadingsByUser ($userid) {
    $recordset = $this->db->query("SELECT article.id,article.title,article.preface FROM articles JOIN users ON article.userID=user.id WHERE article.userID='$userud'");
    while ($article = $recordset ->fetchObject() {
      $articles[] = $article;
    }
    return $articles;
  }
As you can see, the difference between this and using a DAO in a Transaction Script is that the Gateway returns an array of objects which moves your logic away from the RecordSet idea (used internally) to more standard data structures.

Posted: Wed Mar 29, 2006 10:54 am
by Maugrim_The_Reaper
I use OOP in PHP, quite a bit actually...but I have a hell of a time using classes for anything database related...

I feel you loose reuse when you have SQL statements inside a member function, kind of like you loose reuse of a class with HTML inside member functions.
Just a few comments. ORM or ActiveRecord type solutions can be very re-useable if you limit their functionality in certain ways - it's when you reach the complex SQL operations that re-use heads out the window. That said I find myself leaning towards an ActiveRecord/DAO type parent class with standard, re-useable CRUD operations, and extending that with non-reuseable domain objects.... I've also used a few scripts to generate such classes (or at least the basis of them) from database table information, in conjunction with a predefined naming system. It's a bit of a challenging area to code in, but there are shortcuts to maximise re-useability for some parts of this design, but there's no escaping the need for specific methods for specific tables - hence we have gateway classes to encapsulate these behind an API.

On a side note - assuming you intend supporting multiple databases (I use Postgres mostly, and MySQL less) there nothing stopping you from using something like ADOdb with such a structure to execute generated queries, and handle certain aspects of database querying to lessen the complex of the end resulting classes.

Posted: Wed Mar 29, 2006 12:20 pm
by alex.barylski
Maugrim_The_Reaper wrote:
I use OOP in PHP, quite a bit actually...but I have a hell of a time using classes for anything database related...

I feel you loose reuse when you have SQL statements inside a member function, kind of like you loose reuse of a class with HTML inside member functions.
Just a few comments. ORM or ActiveRecord type solutions can be very re-useable if you limit their functionality in certain ways - it's when you reach the complex SQL operations that re-use heads out the window. That said I find myself leaning towards an ActiveRecord/DAO type parent class with standard, re-useable CRUD operations, and extending that with non-reuseable domain objects.... I've also used a few scripts to generate such classes (or at least the basis of them) from database table information, in conjunction with a predefined naming system. It's a bit of a challenging area to code in, but there are shortcuts to maximise re-useability for some parts of this design, but there's no escaping the need for specific methods for specific tables - hence we have gateway classes to encapsulate these behind an API.

On a side note - assuming you intend supporting multiple databases (I use Postgres mostly, and MySQL less) there nothing stopping you from using something like ADOdb with such a structure to execute generated queries, and handle certain aspects of database querying to lessen the complex of the end resulting classes.
All day yesterday and today I've been reading about OR/M...sounds like what I'm after...solves my problems nicely and then some :)

Now I just need to find and choose a PHP implementation :)

Whats the difference between OR/M and Gateway?

Cheers :)

Posted: Wed Mar 29, 2006 12:55 pm
by timvw

Posted: Wed Mar 29, 2006 3:45 pm
by Christopher
Hockey wrote:Whats the difference between OR/M and Gateway?
A Gateway does not do any mapping of object properties to database fields -- so it is much simpler.

Posted: Wed Mar 29, 2006 3:58 pm
by Gambler
timvw wrote:What is "query paradigm"?
Query paradigm is when you issue one big command and get the responce back. There is also navigational paradigm, where you issue number of commands and consult intermediate responces to determine subsequent commands. You used HTML as an example of something similar to SQL, and I will do the same. Currently, people are trying to break away from query paradigm in HTML/HTTP. That's why they adopt AJAX. (Well, that and a good deal of braiwashing from interested parties.)
I dismissed them as implementation details, because your statements addressed SQL dbms (a flawed implementation of a dbms based on the relational model) and not the relational model itself.
What would be an example of better implmentation of relational data model?

Posted: Thu Mar 30, 2006 12:52 pm
by timvw
Gambler wrote: Query paradigm is when you issue one big command and get the responce back. There is also navigational paradigm, where you issue number of commands and consult intermediate responces to determine subsequent commands. You used HTML as an example of something similar to SQL, and I will do the same. Currently, people are trying to break away from query paradigm in HTML/HTTP. That's why they adopt AJAX. (Well, that and a good deal of braiwashing from interested parties.)
I don't really see the link between (query vs navigational paradigm) and (synchronous vs async http requests).

query paradigm: a form of querstioning.
navigational paradigm: determination of direction and position.

synchronous: event that takes places in a fixed time relationship to another event.
asynchronous: not synchronized.
Gambler wrote:What would be an example of better implmentation of relational data model?
http://dbappbuilder.sourceforge.net/Rel.html is a start.