Richard Davey wrote:
Hello Justin,
Monday, February 23, 2004, 5:30:16 PM, you wrote:
JP> The real hairy part is dealing with joins as the syntax is very
JP> different across the DBs. This can be solved by simply not doing them or
I wish :)
JP> using a syntax that most use. Or you can try to u
Hello Justin,
Monday, February 23, 2004, 5:30:16 PM, you wrote:
JP> The real hairy part is dealing with joins as the syntax is very
JP> different across the DBs. This can be solved by simply not doing them or
I wish :)
JP> using a syntax that most use. Or you can try to use DB_DataObject, but
Richard Davey wrote:
Hello Justin,
Monday, February 23, 2004, 4:11:40 PM, you wrote:
JP>3) A unified architecture for mysql and Oracle. You don't have to
JP> remember different functions for use with different databases.
That abstraction only abstracts the functions to connect to, select and
Hello Justin,
Monday, February 23, 2004, 4:11:40 PM, you wrote:
JP>3) A unified architecture for mysql and Oracle. You don't have to
JP> remember different functions for use with different databases.
That abstraction only abstracts the functions to connect to, select and
query the database,
Lukas Smith wrote:
Justin Patrin wrote:
I think you're confusing the issue. PEAR DB does support many
databases, but it only loads the code for the ones that you are
currently using. So if you're using one database it is effectively a
one database API.
Jakes wrote:
What is performance like u
Justin Patrin wrote:
I think you're confusing the issue. PEAR DB does support many databases,
but it only loads the code for the ones that you are currently using. So
if you're using one database it is effectively a one database API.
Jakes wrote:
What is performance like using this class? I've
6 matches
Mail list logo
