Jacob Santos

Question: SDO is sweet, why aren’t developers using it?

Developers will eventually start using it, it will take some time to go from the PHP way to SDO way. It would be easier to jump into SDO once better, more easily interpreted and simple to understand tutorials, code samples, and support is available. IBM tutorials are a little bit technical, with words and complex pictures (UML). Just give me code and explain how it works and let me run with the SDO scissors in my hand.

I just hope IBM and Zend continue the development and not back out, because of the impression that not a lot of developers are using it. The initial investment will pay off once more developers take a look at the wild animal SDO is and say, “Yes, this is awesome!”

My interest was that, in theory, SDO would save a great deal of work. It isn’t a matter of just recoding the source input from database to XML and back again. The switch would require a lot of work, but at least there is a common API which allows for the reading to be handled with consistency.

XML and Databases, but where is Spreadsheet Support?

The reason for why SDO isn’t used as often as some would probably like is because the two things that it currently offers are well taken care of in PHP. You can never have to many choices for handling XML, but combinations of multiple XML extensions can take care of most tasks. For databases, most are going to use MySQL (or MySQLi) or PDO and do you need anything else?

SDO offers the promise of offering more features, but PHP developers will have to do the implementation. Perhaps the two are for basing other future SDO extensions, but it was most likely a lot of programming to offer both XML and Database connections. Two of which would be very difficult from userland. I would like to see access to spreadsheets offered and any number of things that SDO can access.

XML: To many choices

Is that even possible as difficult as XML can be? Many choices are pretty bitchin and even more would be even better.

You have DOM, SimpleXML, XMLReader, XMLWriter, SOAP and WDDX, and finally SDO. If you are really hardcore, you don’t need any of those and just write your own package (not recommended for the sane).

For my work, I use DOM to write XML pages and DOM along with SimpleXML to read XML pages. DOM is quite powerful, and is also very difficult for some tasks and for simple reading, SimpleXML is far better. It helps that DOM and SimpleXML have functions for switching between the two easier. All you’ll need until XMLReader and XMLWriter, which I haven’t used, but does look like I’ll just love and will use them both in the future.

SDO is enchanting with its ArrayAccess for XPath, and I’ll be using SDO XML for that. I’m just not quite “down” with DOM XPath yet and probably won’t be for some time. It is really the only feature for me that gives it an advantage over the other choices, besides ArrayAccess property access.

Databases

Updated: It seems some comments made weren’t based on fact, so I decided to rewrite parts of this section to correct those flaws.

For my development with ArrayAccess it would make more sense to use SDO over PDO, because SDO already has that feature. If I used PDO I would have to write the ArrayAccess method myself. It would save time to use SDO in that case. For those who don’t care about ArrayAccess, PDO probably would be a more logical choice.

Possible reasons for not using SDO include:

1. Current speed comparsions of mysql extensions verses PDO suggests that PDO is slower by a considerable degree without emulating prepares. SDO uses PDO for the Relational part, so it is safe to say that SDO will be as fast as PDO if not slower.
2. SDO has even more complexity than PDO and the PDO learning curve hasn’t so far been so great. SDO seems easy, as does PDO, but there are probably going to be “gotchas”, like in PDO, that would need to be covered. The best way to use SDO as it was intended and not coding it hackish-ly will also have to be covered in better detail.

To put it bluntly and I’m repeating what others have simply stated before, is that more people are going to use PDO for their database Data Object. SDO still uses PDO, but it is still another layer that developers might not care about.

Conclusion

I’m sorry if I ask a lot more questions, but such SDO requires a great deal of thought for any project. It would be nice if every developer used it, to make working on projects easier. It just needs to offer more backends.

In a couple of years, we’ll look back and ask what the big fuss over developers not using SDO was about. I’m quite sure that enough PHP developers are going to embrace SDO in the coming years depending on the coverage it gets that IBM and Zend’s investment will pay off in the end.

Possibly Related Posts:

• Bullet: E-Book Library Management and Content Server
• Using ZendFramework 2 beta1 For Directory Project
• The Way of Kings and Cosmere Theory
• “In Time” Movie Premise Flawed
• Completing HTTP Library For PHP