SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 26
  1. #1
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)

    SDO - Is it worth considering?

    Hi,

    I reviewed sitepoint 2005, 2006, and 2007 posts regarding SDO. I am a bit afraid to ask as it does not seem as many Sitepointers are talking about (or perhaps using SDO).

    If you want to use flexible data source mapping to a given applications, would you at this time consider SDO to be mature, full featured or not overly myred in politics to be considered useful?

    Zend put out this: http://devzone.zend.com/node/view/id/1085 that seemed interesting and fairly straight-forward and also http://ca.php.net/sdo which illustrates XML based datasource.

    I know that many posts that I reviewed advocated the fact that because PHP is so easy to refactor that adding a lot of extra complication communication to the datasources may be overkill in too many types of projects and it is better to tailor SQL to meet the RDBMS uniquenesses and get the added benefit of greater flexibility with simpler solutions.

    However, if you are stuck in-between a large and small project but would like to design the applications API to be extendible then does it make sense in thinking about something like SDO or instead implementing TableDataGateway, ActiveRecord or a self-roled DataMapper patterns?

    Regards,
    ServerStorm
    ictus==""

  2. #2
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I took a look at this a while back and came to the conclusion that with PHPs architecture there wouldn't be too many advantages; In my mind, web services would be the better of the two evils;

    The one advantage of SDO is easier and a more pliable approach to distribution, not so much for your application it's self, but the data in regards to what your application is able to communicate with.

    Personally I would stick with web services for the time being, but if there were some concrete backing from IBM, then my view may well change. For me, it's wait and see

  3. #3
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Dr

    So if currently your datasource is a MySQL database but there is a pretty good chance that it will be Oracle in the not too distance future that you would code the system more tightly coupled with MySQL and when Oracle comes along ripple the database through the domain and data classes; Or, are you saying that if in the future XML or R.S.S or another type of datasource come along in the future you would web-services to facilitate the exchange of data with your application?

    Regards,
    ServerStorm
    ictus==""

  4. #4
    SitePoint Addict miggl's Avatar
    Join Date
    Feb 2007
    Location
    Los Angeles, CA
    Posts
    286
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Regarding the possibility of the datasource changing from one DBMS to another, perhaps even mid-project, I would recommend a DAL and perhaps even an ORM layer.

    DAL basically makes your access to the database independent of the database type, so you don't have to change any (or only minimal) code when switching between database providers. However, you must have the database schemas setup in an identical manner.

    The ORM will further abstract the way you interact with the database so that you no longer write SQL queries, but instead the ORM creates an object-oriented abstraction of your database, giving you PHP objects that you can use to manipulate and get your data.

  5. #5
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Hi miggl

    Thanks for your reply!

    I got looking into SDO after reviewing a bunch of the sitepoint wizards talk about ORMs I got the impression that most of them felt there were limited uses and or usefulness with ORM and PHP. Also bigger gripes were that they restricted more flexible types of SQL queries and caused excessive processing overhead.

    I will have to re-read about DAL to see if this is right for my project, but from what you say, it may be right?

    Regards,
    ServerStorm
    ictus==""

  6. #6
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    At the moment I develop with MySql but if the issue arose that I would have to develop with Oracle, then currently I could easily enough, I suppose.

    Sure, there would be some additional work to do in some regards to the domain, but none that I couldn't cope with. For the most part it would be a case of switching out the SQL, that is if the schema were the same - by that I mean the relationships between the tables, and not the data types of each table.

    The column data types are not here nor there, as in regards to the domain it's self; The domain doesn't (or at least shouldn't) know of the schema.

    At the moment I don't see any advantages of SDO that what other tools are available, could manage easily enough, compared with SDO; You could continue to develop happily enough without SDO, and still maintain that loose coupling.

    As I said, where SDO does help, is to offer you an olive branch to distribute your data more easily between different sources, but you can do that anyway with web services. Maybe I'm missing something, but if you already have tool, and it ain't broken...

  7. #7
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Hi Dr.

    I think from what you said earlier and other non-sitepoint info I have reviewed since posting this, I will not be using SDO.

    I hear you what you are saying regarding the changes in the domain and data layers and I agree that these changes would be manageable.

    I think Web Services will be just fine to gain access to some different types of datasources.

    After reading most the day about this (in attempt to answer the question about a good way to separate the data layer from the other objects in the system) I will likely try to create Data Mappers for the different objects.

    It is hard for me to make this decision as I have never implemented any thing other than using one of Harry F's MySQL scripts (PHP Anthology) for php 4 and now creating fairly direct connections, using PDO in Php 5.x, therefore I am just going to take a step and try Data Mappers as they seem mid way in complexity yet describe the level of database separation that I would like.

    Thanks for your thoughts,
    ServerStorm
    ictus==""

  8. #8
    SitePoint Addict miggl's Avatar
    Join Date
    Feb 2007
    Location
    Los Angeles, CA
    Posts
    286
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ServerStorm, you may want to look into using a good quality framework to do the heavy lifting for you (that way you won't have to create your own). These include projects like symfony, Zend FrameWork, and CakePHP. symfony has a bundled DAL and ORM, while ZFW only has a DAL (ORM is likely to be added in the future). I haven't researched CakePHP yet, but I believe it also includes an ORM as well as a DAL. The ORM bundled with symfony is probably the best PHP ORM at the moment (PROPEL), but you mentioned that they seem to have alot of overhead (which I have not yet verified).

    Implementing a framework is probably faster for you to learn that it would be to write your own DAL. If a DAL is all you need, then you can implement one of those on its own (I have used PEAR MDB2) as well, and its a very quick installation task; you'll be up and running within 2 to 3 hours (if you're learning it from scratch).

  9. #9
    SitePoint Enthusiast
    Join Date
    Feb 2006
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There is also Doctrine (www.phpdoctrine.net). Its an ORM framework that uses ActiveRecord pattern, derives from MDB2 and has many advanced features of such ORM gorillas as Hibernate

  10. #10
    SitePoint Addict miggl's Avatar
    Join Date
    Feb 2007
    Location
    Los Angeles, CA
    Posts
    286
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the link, zYne, I'll be interested to check that one out as well.

  11. #11
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I had a look at it a while ago, but the fact that it has no multibyte-character support was a major turn-off for me. Until that comes, I wouldn't consider the library mature.

  12. #12
    SitePoint Addict miggl's Avatar
    Join Date
    Feb 2007
    Location
    Los Angeles, CA
    Posts
    286
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    I had a look at it a while ago, but the fact that it has no multibyte-character support was a major turn-off for me. Until that comes, I wouldn't consider the library mature.
    A limitation like that is definitely a huge turnoff. I'll have to take a look at it and see if they are planning to implement it. Thanks for the warning!

  13. #13
    SitePoint Wizard silver trophybronze trophy Cups's Avatar
    Join Date
    Oct 2006
    Location
    France, deep rural.
    Posts
    6,869
    Mentioned
    17 Post(s)
    Tagged
    1 Thread(s)
    I have been mildly plotting the course of SDO too.

    At the London PHP conference I saw a very interesting presentation by Simon Laws about SCA. That is in PECL now, and the presentation - though very simple - explained nicely how SCA components can be very decoupled, it was especially topical as it followed Cal Evans talk on mashups.

    The talk is linked from foot of this page.

    http://www.osoa.org/display/PHP/SOA+PHP+Homepage

    Trusting this adds to the conversation.

  14. #14
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    The SDO library has an excellent pedigree. It's unusual in that it's OptimisticLock and UnitOfWork based. If you have long transactions, or are passing objects within internal APIs, this is an excellent choice.

    The data object style is more like something out of LDAP from the demos (I haven't tried it myself yet), rather than relational or pure OO. You have to get past a load of TLAs as well, which clouds it's usability somewhat.

    Still, I reckon it's an excellent library. We had the SCA talk on the back of the strength of SDO.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  15. #15
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    miggl

    It is always a bit of a quandary at my current level of PHP development if I should use a framework or (some one else's code) or, to learn, do it myself. As I have never written a data mapper then I almost want to try myself. However, then I read Fowler saying POEAA (page 117)
    Remember that you don't have to build a full-featured database-mapping layer. It's a complicated beast to build, and there are products available to do this for you. For most cases I recoomend buying a database-mapping layer rather than building on yourself.
    which your recommendations echo.

    I would currently like to stay away from a framework a little longer so that I can learn about some of the mechanics. Periodically I download Zend and try to study what the developers are doing - I also do this with WACT, but I am really trying to learn before I help myself in this way. However, I hope that you can take from this that I do think that the advice is good, just not for me right now.

    I still haven't ruled out a DAL however some of the posts in this thread have again peeked my interest in SDO. I is a lot to think through, because after I release this product I can't exactly go back to the 20 or 30 initial companies that use it and say "hey I made a mistake on the choice of database implementation and I want to change it" especially since they will likely use the API that I provide to extend the application.

    Thanks,
    ServerStorm
    ictus==""

  16. #16
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    zYne

    Thanks for your link to Doctorine. I did some earlier reading on sitepoint when you first created Doctorine and there were some pretty spirited conversations around that time . I will definitely take a look!

    Thanks,
    ServerStorm
    ictus==""

  17. #17
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    kyberfabrikken

    Re the Multi-Byte character support. I did read about that and their take was they would wait and see if the community pushed for it. My product will likely not be sold in any place other then Canada and the U.S. and so I am thinking that this will not be a big impediment. However many of you may laugh at this as being to naive or short-sighted .

    Thanks,
    ServerStorm
    ictus==""

  18. #18
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Cups

    Thanks for the info it was interesting to read. I am curious regarding the comment
    I have been mildly plotting the course of SDO too.
    Why only 'mildly plotting', something holding you back or just haven't had the right sort of project yet?

    Regards,
    ServerStorm
    ictus==""

  19. #19
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Hi Marcus,

    Sorry I don't know which definition TAL is:
    • Typed Assembly Languages
    • Template Attribute Language
    • Transaction Application Language
    • ...?
    However after reading (and re-reading) POEAA I thought that I would attempt to incorporate Optimistic Locking and UnitOfWork pattern, so I am glad to hear that SDO utilizes these.

    If I was to use SDO, what would you expect to be the limitations I would face in attempting to build a pure to mostly pure OO type application [ hopefully this question is not to broad ]?

    Thank you for your time!

    ServerStorm
    ictus==""

  20. #20
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Sorry, that should have been TLA - three letter acronym.

    You will always have some kind of compromise. OO is about data hiding, databases are about searching. There is bound to be conflict.

    If you lean to perfect objects with invisible persistence mapped on to an arbitrary schema, then something full on like Hibernate (that's Java) will be ideal.

    If you want good objects, control the schema, and have modest searching and transaction requirements, then an automated ActiveRecord/Finder combination is the way to go.

    If you don't mind data like objects, have an arbitrary schema and don't have complicated searching, then RowDataGateway type automations might be for you.

    If you have arbitrary queries and uncontrolled schemas, and still want good objects, then hand coded ActiveRecords could be the way to go.

    If you have arbitrary untransactional queries and uncontrolled schemas, and piping your data straight into reports, then doing your data work in SQL may be better.

    If you have transactional operations, arbitrary queries and uncontrolled schemas, then stored procs and service classes may be the way to go.

    If you have transactions, want good objects, are doing a lot of CRUD with webs of objects, then you want UnitOfWork for sure.

    So, it depends .

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  21. #21
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft View Post
    We had the SCA talk on the back of the strength of SDO.
    SCA looks great for creating web services. I cornered Simon Laws for about 3.5 seconds at the conference and asked him whether or how this would be useful to me if I'm only on the client side, consuming web services. He replied that SDO would be more relevant. I still haven't been able to figure it out from the documentation, though.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  22. #22
    SitePoint Guru
    Join Date
    May 2005
    Location
    Finland
    Posts
    608
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    I had a look at it a while ago, but the fact that it has no multibyte-character support was a major turn-off for me. Until that comes, I wouldn't consider the library mature.
    Are you referring to Doctrine? If so, could you point out what kind of things - and how - would you have expected it to handle for you?

  23. #23
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ServerStorm View Post
    Re the Multi-Byte character support. I did read about that and their take was they would wait and see if the community pushed for it. My product will likely not be sold in any place other then Canada and the U.S. and so I am thinking that this will not be a big impediment. However many of you may laugh at this as being to naive or short-sighted
    For me it's more a matter of principle. I get very suspicious about someone, who builds a data abstraction layer and don't make unicode first priority. Almost all the work going into the development of PHP6 is rewriting of parts to use unicode strings. That's a lot of work to correct your mistakes, and because of that, it has taken far too long to get it done.

    That aside, I'm sure there are people in the states with foreign characters in their names.

  24. #24
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Ezku View Post
    Are you referring to Doctrine? If so, could you point out what kind of things - and how - would you have expected it to handle for you?
    http://www.php.net/sdo
    The following are limitations in the current SDO implementation:
    • There is no support for multi-byte character sets. This will be considered, depending on community requirements, in the Unicode-enabled version of PHP. See Unicode Functions.

  25. #25
    Foozle Reducer ServerStorm's Avatar
    Join Date
    Feb 2005
    Location
    Burlington, Canada
    Posts
    2,699
    Mentioned
    89 Post(s)
    Tagged
    6 Thread(s)
    Hi Markus

    Hi Marcus,

    Thanks for the break-down of the different types of processes that might be better served by the approaches you outlined. Your post will serve as a good reference for me until I can internalize this knowledge.

    I think that this is the best fit for my requirements:
    If you have transactions, want good objects, are doing a lot of CRUD with webs of objects, then you want UnitOfWork for sure.
    Sorry, that should have been TLA - three letter acronym.
    LOL - my mild dyslexia got the better of me on that one and ironicly because of it you have to explain the three letter acronym for three letter acronym.
    ictus==""


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •