SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 29

Thread: PDO v MySQL

  1. #1
    SitePoint Guru
    Join Date
    Feb 2007
    Posts
    731
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    PDO v MySQL

    Hi,

    I am currently using MySQL but I have been advised a number of times that I should be using PDO.

    The problem is I dont understand what PDO is and how it is different to MySQL. If you had a code run on MySQL how would you change it to PDO?

  2. #2
    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)
    Try one of these PDO tutorials.

    This will only be of any use to you after you decide to go and learn how to use SQL properly of course. This book is good: Simply SQL by Rudy Limeback (and he's a Sitepoint mentor on the sql forum here).
    Last edited by Force Flow; Oct 7, 2012 at 12:10. Reason: Corrected spelling of Rudy's name

  3. #3
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,240
    Mentioned
    155 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by justlukeyou View Post
    Hi,

    I am currently using MySQL but I have been advised a number of times that I should be using PDO.

    The problem is I dont understand what PDO is and how it is different to MySQL. If you had a code run on MySQL how would you change it to PDO?
    The short answer, PDO is very similar to MySQLi, it teaches you to use an OO approach (or at least you can use an OO approach), and more importantly teaches you to not have SQL injections by using prepared statements or binding your values when executing your SQL.

    MySQLi and PDO provide helpers that automatically sanitize your values for you provided you USE those helpers and don't just concatenate the values into your SQL query. Although you can follow countless articles found on google, I'll reference the php manual, which shows you a prepared statement and the syntax it uses so that PDO can sanitize your input for you to remove a SQL injection attack.

    Quote Originally Posted by Cups View Post
    Try one of these PDO tutorials.

    This will only be of any use to you after you decide to go and learn how to use SQL properly of course. This book is good: Simply SQL by Rudy Limeback (and he's a Sitepoint mentor on the sql forum here).
    I don't think he is a "designated" mentor, but he definitely runs the SQL Forum very well

  4. #4
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,341
    Mentioned
    63 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Cups View Post
    This book is good: Simply SQL by Rudy Limeback (and he's a Sitepoint mentor on the sql forum here).
    thanks for the kind words

    you should probably just link to sitepoint's book page -- http://sitepoint.com/books/sql1

    i used to be a mentor (then an advisor, and then a team leader), but i gave all that up after several years, and now i just answer easy questions

    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  5. #5
    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)
    Duly noted.

    @rudy ; "just answer easy questions" -- that sounds like me too

  6. #6
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,341
    Mentioned
    63 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Cups View Post
    @rudy ; ...
    fyi, that's not me, that's some other member
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  7. #7
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    The short answer, PDO is very similar to MySQLi, it teaches you to use an OO approach (or at least you can use an OO approach), and more importantly teaches you to not have SQL injections by using prepared statements or binding your values when executing your SQL.
    I'm not really fond of using prepared statements as a way of avoiding SQL injections but at least the code is secure that way.

    And I hope I won't open a can of worms with this statement

  8. #8
    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)
    What do you prefer to use then, if not prepared statements?

  9. #9
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,240
    Mentioned
    155 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    I'm not really fond of using prepared statements as a way of avoiding SQL injections but at least the code is secure that way.

    And I hope I won't open a can of worms with this statement
    Quote Originally Posted by Cups View Post
    What do you prefer to use then, if not prepared statements?
    I too am interested in what you prefer to use. If you prefer to use the MySQLi functions and utilize mysqli_real_escape_string, I won't complain, but I do think you are doing more work than necessary (as MySQLi even has prepared statements).

  10. #10
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    What do you prefer to use then, if not prepared statements?
    Quote Originally Posted by cpradio View Post
    If you prefer to use the MySQLi functions and utilize mysqli_real_escape_string, I won't complain, but I do think you are doing more work than necessary (as MySQLi even has prepared statements).
    Yes, it's as simple as that, I prefer to use the functions that were designed for this purpose: mysqli_escape_string or PDO::quote - I always use them in a convenience wrapper class so that I can type less.

    I don't think it's more work than necessary, actually I think it's much less work. Preparing a statement with objects and methods, binding values and then executing is more work than simply concatenating parts of string using simple $db->quote() calls. For me a php statement for concatenating parts of string preserves natural flow of logic in code (things are happening in simple succession) as opposed to segmented preparing of a query where you have the query with placeholders separately and then the referencing placeholders again with their bound parameters to match. Therefore, I consider the concatenation to be more readable even though it doesn't look that 'professional'.

    I think that the primary reason for prepared statements is preparing queries for multiple execution with different parameters so that there is gain in performance because the query is parsed only once. Other than that I consider it a bit crazy to prepare something as simple as an SQL query to use it once and ditch it. If we extended the idea a little further we might end up preparing every string we use in php with specialised objects, which would result in at least 3 times as much code to write. This might appeal to Java programmers, though

  11. #11
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,240
    Mentioned
    155 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    Yes, it's as simple as that, I prefer to use the functions that were designed for this purpose: mysqli_escape_string or PDO::quote - I always use them in a convenience wrapper class so that I can type less.

    I don't think it's more work than necessary, actually I think it's much less work. Preparing a statement with objects and methods, binding values and then executing is more work than simply concatenating parts of string using simple $db->quote() calls. For me a php statement for concatenating parts of string preserves natural flow of logic in code (things are happening in simple succession) as opposed to segmented preparing of a query where you have the query with placeholders separately and then the referencing placeholders again with their bound parameters to match. Therefore, I consider the concatenation to be more readable even though it doesn't look that 'professional'.

    I think that the primary reason for prepared statements is preparing queries for multiple execution with different parameters so that there is gain in performance because the query is parsed only once. Other than that I consider it a bit crazy to prepare something as simple as an SQL query to use it once and ditch it. If we extended the idea a little further we might end up preparing every string we use in php with specialised objects, which would result in at least 3 times as much code to write. This might appeal to Java programmers, though
    I've actually got more of a .NET background anymore and prepared statements appeal to me, but purely because at my old job, we forced the use of Stored Procedures for ALL queries (no ad-hoc queries allowed). Why? Because of performance, SQL Server has major performance improvements it applies to stored procedures versus ad-hoc queries. Whether they are run once an hour or 10 times in a row, you will see a benefit. Prepared Statements in my mind tries to fill that void in MySQL's default (is it still the default engine?) MyISAM engine. INNODB allows stored procedures (I really don't know if MyISAM allows them yet or not), but I welcome the change, granted it isn't as powerful as the database handling it (as it only helps during the single execution (I think) and can't be applied across all requests). So I do understand your argument all too well.

    Personally so long as data is sanitized, I can careless what method is used, but I do find it easier to tell people to use ->prepare() in MySQLi or PDO as it is one less thing you have to teach them, as the sanitizing of the data is handled automatically for them (granted, I'll still mention the method provided helps guard against SQL Injections).

  12. #12
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cpradio View Post
    Because of performance, SQL Server has major performance improvements it applies to stored procedures versus ad-hoc queries. Whether they are run once an hour or 10 times in a row, you will see a benefit.
    AFAIK Mysql doesn't have the performance benefit of stored procedures because they are parsed every time they are called. You also lose the benefit of the query cache when using stored procedures so I think ad-hoc queries are the fastest - Mysql still has a long way to catch up!

    Quote Originally Posted by cpradio View Post
    Prepared Statements in my mind tries to fill that void in MySQL's default (is it still the default engine?) MyISAM engine. INNODB allows stored procedures (I really don't know if MyISAM allows them yet or not), but I welcome the change, granted it isn't as powerful as the database handling it (as it only helps during the single execution (I think) and can't be applied across all requests). So I do understand your argument all too well.
    InnoDB is default as of Mysql 5.5. But I don't think the db engine has anything to do with prepared statements or stored procedured as they are completely different things. Statement preparation is handled by Mysql core not by the engine so you can use then with any engine.

    Quote Originally Posted by cpradio View Post
    Personally so long as data is sanitized, I can careless what method is used, but I do find it easier to tell people to use ->prepare() in MySQLi or PDO as it is one less thing you have to teach them, as the sanitizing of the data is handled automatically for them (granted, I'll still mention the method provided helps guard against SQL Injections).
    I was always wondering about this reasoning because whether you use ->prepare() or sanitise a value you have to do something with it, you can't just inject it directly into the query. Even if people use prepared statements there's nothing preventing them to insert a $var into the query directly and then the security is compromised. They have to consciously think in each case to prepare the value or to sanitise so I don't see much difference. Or maybe it's this simple rule - no string concatenation allowed when writing SQL in PHP?

  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)
    @Lemon Juice ; Thank you for the interesting reply, I'm going to bear that in mind.

    I suppose that part of my motivation for extolling the use of prepared statements is fuelled mostly by wanting to help less experienced coders a less error-prone means of protecting their databases.

    For a coder new to using classes, being faced with not only learning PDO but PDOStatement too must be quite a daunting task (well it was for me, as I recall). So, maybe I'll think again next time.

  14. #14
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,240
    Mentioned
    155 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Lemon Juice View Post
    AFAIK Mysql doesn't have the performance benefit of stored procedures because they are parsed every time they are called. You also lose the benefit of the query cache when using stored procedures so I think ad-hoc queries are the fastest - Mysql still has a long way to catch up!
    Well that blows! What was their reasoning for implementing stored procedures then? Takes all of the benefits out (I did some googling and found you were "spot on" on this).

    Quote Originally Posted by Lemon Juice View Post
    InnoDB is default as of Mysql 5.5. But I don't think the db engine has anything to do with prepared statements or stored procedured as they are completely different things. Statement preparation is handled by Mysql core not by the engine so you can use then with any engine.
    My thinking was at one point InnoDB was the only engine to support stored procedures, since there is no benefit there (as you have proven), my statement didn't help anything.

    Quote Originally Posted by Lemon Juice View Post
    I was always wondering about this reasoning because whether you use ->prepare() or sanitise a value you have to do something with it, you can't just inject it directly into the query. Even if people use prepared statements there's nothing preventing them to insert a $var into the query directly and then the security is compromised. They have to consciously think in each case to prepare the value or to sanitise so I don't see much difference. Or maybe it's this simple rule - no string concatenation allowed when writing SQL in PHP?
    Yes, that would be the idea, if you teach them to use prepare, you tell them they cannot concatenate a variable to the query, otherwise, it is all for nothing.

    In the end, prepare just fell a few notches from my list. Not sure which I would imply more often yet, but if MySQL fixes their stored procedure fubar then I'll be recommending it more often again. *sigh*

  15. #15
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    I'd like to add a few points.

    PDO is an abstraction layer, which makes it easier to change your target DBMS without having to change your code.

    A prepared statement is an SQL statement written with placeholders. Upon first use, your target DBMS is asked to compile (optimize it). You client code may then call it repeatedly with different parameters.

    A stored procedure is also an SQL statement written with placeholders. It is designed and exists entirely within the DBMS. It is compiled on creation, or on alteration. All clients that call it, are calling the same procedure. They can also be associated with a schema, have user and login level permissions, and other things.

    Here's a few points of interest:

    1) A prepared statement cannot be stored.
    2) You can use a PDO prepared statement to call a stored procedure, assuming your DBMS (E.G. MSSQL) supports them.

  16. #16
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Correction, PDO is a data-access abstraction, not a Database abstraction. (Database-specific functions/methods are available with different DB drivers.)

    http://www.php.net/manual/en/intro.pdo.php
    PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility.
    (PDO does not emulate missing features, except prepared statements.)
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  17. #17
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    That is correct. I apologize if my first statement was missleading. I was in a hurry (trying to get my kids off to school). It is true that not all databases use the same SQL syntax. Some changes may be required from time to time.

  18. #18
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,653
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    FYI, in current versions of SQL server the real "win" for SProc performance is that the server can very effectively cache the execution plan because it is fixed. The same actually applies to dynamic SQL with proper variable binding but the trick is dynamic sql is, well, dynamic so it isn't always as consistent. Still, if you have a data layer generating SQL it should be consistent enough that query performance will be approaching that of stored procedures.

    The way I'd look at this question is really "Is there any reason not to use PDO and prepared statements." I can't think of one outside of "I'm working with an existing codebase that doesn't use it."

  19. #19
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,240
    Mentioned
    155 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wwb_99 View Post
    FYI, in current versions of SQL server the real "win" for SProc performance is that the server can very effectively cache the execution plan because it is fixed. The same actually applies to dynamic SQL with proper variable binding but the trick is dynamic sql is, well, dynamic so it isn't always as consistent. Still, if you have a data layer generating SQL it should be consistent enough that query performance will be approaching that of stored procedures.
    Unfortunately, for MySQL, it doesn't do that globally, it does it per connection, which makes it meaningless (Source)

    Quote Originally Posted by wwb_99 View Post
    The way I'd look at this question is really "Is there any reason not to use PDO and prepared statements." I can't think of one outside of "I'm working with an existing codebase that doesn't use it."
    Well, to be honest, because I believe (but can't prove it yet; haven't found the documentation to support it yet -- if you know the answer to this, I'm interested) the preparation only keeps for the given request, beyond that, it is lost, so other requests don't get to take advantage of the user before them already running that query. This is where if SProcs worked properly in MySQL and it cached the execution plan globally and not per connection, then it would make sense to always recommend prepared statements. But the way it seems to work goes against all expectations and you end up spending time for PHP to cache/compile/optimize a query used for a single request.

    Granted, that is ALL under the assumption you are using MySQL. If you are using PDO with SQL Server, you are going to do great things with PDO's aid in terms of performance optimization.

  20. #20
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Is it just me, or has this gone a bit off track (though interesting). The original quandry was about using Mysql via PDO (prepared statements) versus using MySql directly (and therefore real escape string) was it not? More accurately, it was more about the differences between the two, correct? We seemed to have migrated into a discussion on performance benefits of stored procs, prepared statements, and so on. Just saying.

  21. #21
    SitePoint Member
    Join Date
    Sep 2012
    Location
    Australia, Queensland
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PDO is considered to be a standard, that's why you were advised to use it.. MySQL was primarily a bespoke solution to a certain problem, but it has all the problems of the other DBMS-specific libraries. PDO is where you should implement all your clever thinking and hard work : http://net.tutsplus.com/tutorials/ph...ge-1/#comments

  22. #22
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,240
    Mentioned
    155 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Serenarules View Post
    Is it just me, or has this gone a bit off track (though interesting). The original quandry was about using Mysql via PDO (prepared statements) versus using MySql directly (and therefore real escape string) was it not? More accurately, it was more about the differences between the two, correct? We seemed to have migrated into a discussion on performance benefits of stored procs, prepared statements, and so on. Just saying.
    Albeit a bit true, however if you replace Stored Proc with Query, the topic still fits. PDO is a data-accecss abstraction that really doesn't work, and it isn't PDO's fault, it is because every database out there choose to customize their syntax with proprietary functions, so you don't have LIMIT everywhere, nor TOP, nor NOW(), or GETDATE(), or whatever.

    So what does PDO provide then? It provides performance enhancements IF you will be executing a similar query within the same request multiple times. If PDO could utilize those optimizations across requests, it would help tremendously (and if it does and I misunderstood that in the manual, oops).

    However, I still argue MOST of that optimization should occur naturally within your database of choice. Not from the language (I related PDO to LINQ to SQL in .NET; yes, it is cool, but you are asking your language to take on overhead that the database should already be handling for you).

  23. #23
    Resident OCD goofball! bronze trophy Serenarules's Avatar
    Join Date
    Dec 2002
    Posts
    1,911
    Mentioned
    26 Post(s)
    Tagged
    0 Thread(s)
    Fair enough. Though I wasn't suggesting the debate end. It's quite interesting.

    Quote Originally Posted by cpradio View Post
    I related PDO to LINQ to SQL in .NET

    I am not sure this is actually very accurate. Linq converts your code statement into proper syntax, depending on usage. LinqToSql for example would generate SQL, while LinqToXML would generate an xpath query, despite the inline code remaining the same. As far as I understand it, PDO doesn't do this. The only real point of sameness is in how connection strings are handled. If there is significant changes in the way a backing storage medium works, some recoding of your statement may be required. Linq2Sql, in specific, is designed to generate SQL Server specific statements. PDO isn't designed to generate SQL, much less be MySQL specific.

  24. #24
    Hosting Team Leader silver trophybronze trophy
    cpradio's Avatar
    Join Date
    Jun 2002
    Location
    Ohio
    Posts
    5,240
    Mentioned
    155 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Serenarules View Post
    I am not sure this is actually very accurate. Linq converts your code statement into proper syntax, depending on usage. LinqToSql for example would generate SQL, while LinqToXML would generate an xpath query, despite the inline code remaining the same. As far as I understand it, PDO doesn't do this. The only real point of sameness is in how connection strings are handled. If there is significant changes in the way a backing storage medium works, some recoding of your statement may be required. Linq2Sql, in specific, is designed to generate SQL Server specific statements. PDO isn't designed to generate SQL, much less be MySQL specific.
    Sorry, I guess the only relation between them is that they both try and enhance performance on a language level that (in my opinion) is better suited on the database side by caching/compiling/optimizing queries as they are sent across the wire. I do agree that LINQ to SQL takes it one step further and helps separate the SQL syntax from your code (that is nice), but there is still overhead in the entire process that can be costly (or more costly) than writing a good set of abstraction classes.

  25. #25
    SitePoint Guru bronze trophy
    Join Date
    Dec 2003
    Location
    Poland
    Posts
    930
    Mentioned
    7 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Cups View Post
    For a coder new to using classes, being faced with not only learning PDO but PDOStatement too must be quite a daunting task (well it was for me, as I recall). So, maybe I'll think again next time.
    Yes, beginners may have problems understanding this, however it's a good exercise in learning how objects work . But I must admit I am not a fan of PDO. I like the idea of a universal database API but the implementation is too complicated IMHO and PDO lacks many simple shortcut methods for frequent operations like fetching a single value, single row, etc. The end result is that I have to always extend PDO (or mysqli) with my own wrapper class to have all those convenience methods because I don't want to type multiple lines of code to perform a simplest database operation - and when I have to use a wrapper then I lose most of the benefit of database independence that PDO provides (sort of). If I need to change db then I modify slightly my wrapper class and that's it, it's not a lot of work considering the non-PDO db extensions are pretty similar.

    Also, I think the default non-buffered PDO results are more awkward to use than the buffered ones (default in mysqli). I remember having problems enabling buffered results in PDO... For example, I wanted to implement fetching multiple-row result set as objects in my simple ORM implementation. Normally, I would pull all rows and insert them into an array of objects. However, I wanted the result to be an Iterator implementing Countable and ArrayAccess - can't do this with unbuffered queries without having num_rows (except pulling all rows into an array first). Struggling with this with PDO I finally went back to mysqli and I'm happy.

    I did try PDO for quite some time and my overall feeling was it's overcomplicated. I can work with it without problems and I understand all the concepts but there's no real benefit I can see.

    Quote Originally Posted by cpradio View Post
    In the end, prepare just fell a few notches from my list. Not sure which I would imply more often yet, but if MySQL fixes their stored procedure fubar then I'll be recommending it more often again. *sigh*
    But prepared statements is a different thing from stored procedures so one doesn't exclude the other. In recent versions of Mysql (5.5, not sure about 5.1) prepared statements properly make use of the query cache if necessary.

    My main point is preparing statements doesn't make any logical sense if it is done only to prevent SQL injection, because this is not their purpose and there are other tools designed for the job. Sure, this will work but in my opinion it's unnecessary. Speed differences are so small that they are not worth worrying about them, at least for mysql.

    For beginners I would advise using mysqli (if you have the luxury to choose) - the advanced people will be able to choose for themselves .


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
  •