I've made a web application using SQLite (2.8.17), I've only now discovered that there's an SQLite3. It somehow eluded my attention when making the web application, probably due to the lack of documentation for the php functions.
I'm wondering, what are the benefits of using SQLite3 over SQLite? Is it considerably faster?
SQLite2 internally stores every value as a string, regardless of its type.
Upgrading to SQLite3 will certainly shrink the database size since numbers and BLOBS get stored in their native formats, which could make things run faster. Another big advantage in my opinion is that recent versions of sqlite, (starting from 3.6.23) support foreign keys.
Since you were using PHP, I would suggest that you look into PDO. It could prove helpful in case you need to change the DBMS for the application
This documents from the sqlite.org website: http://www.sqlite.org/version3.html it doesn't talk about performance, but differences. anyway there are not update to sqlite2 I personally recommend using latest and greatest version 3 (see Improved Concurrency, always good for web applications).
Related
I'm trying to plan a web application that should use a noSQL solution - Cassandra seems to be a good solution. I saw there are libraries for PHP to manipulate the database like phpCassa.
Also I saw the new version of Cassandra 0.8 is introducing a query language CQL.
Are there php interfaces that use the CQL? What is the benefit using the CQL? Is it just a more sql-like way to make queries?
Thank you!
The link Greg posted above is to date the working repo and state of the php-cql driver efforts.
While a driver is not yet available it does not stop you from using CQL, the drivers are all going to be a wrapper of the thrift method "execute_cql_query" (Until a new transport is created anyway).
That means you can simply compile thrift for php or get it from an updated project and then pass your cql query to that method. It does mean manual handling of things that a driver will/should take care of.
"Is it just a more sql-like way to make queries?", basically...yes. One of the things that came up on the Cassandra mailing list was getting CQL to be as SQL-Like as possible.
"What is the benefit using the CQL?" Well, mainly that some new Cassandra users find the thrift API tedious to get to grips with, CQL may be much easier to learn since its is so close to the "normal" sql.
https://github.com/nicktelford/php-cql
I also believe that phpCassa should support it as well.
It's designed to make NoSQL more logical for people coming from SQL as a database engine.
This will really be helpful if you wish to use CQL to communicate with Cassandra via PHP
https://gist.github.com/1024060/983a5607390433b77d5c2e64a4ee148f4df46b69
This is a sample of what zcourts mentioned in his previous post
Regards,
Tamil
The official CQL drivers supported by the Apache Cassandra project at large are, I believe, all on Apache Extras, at this link:
http://code.google.com/a/apache-extras.org/hosting/search?q=label:cql
The PHP one is at
http://code.google.com/a/apache-extras.org/p/cassandra-pdo/
Connection via Thrift deprecated.
I am using PHP library for Cassandra database via a binary protocol.
Both seem to try making it simpler using a database in PHP. Both seem to provide an abstraction over different database types like MySQL, SQLite, etc.
What are the differences between both ADOdb and PDO?
PDO is standard in PHP as of version 5.1. (It is also available with a PECL extension in PHP 5.0) Most hosting provides will have it enabled. AdoDB is not a standard extension.
Also, I believe the PDO drivers are "PHP-native": they are built on top of the same libraries that PHP itself was built on, and use the same underlying routines for things like memory management. So potentially, PDO is more lightweight than AdoDB.
According to this benchmark, AdoDB is considerably slower than PDO: (fixed link)
https://gist.github.com/tony-landis/31483
Of course, you should consider whether this is important enough for your use case to prefer PDO or not.
From a technical perspecitve, the most notable difference would be that PDO is a native extension and, from PHP 5 on, always included in PHP in its fast, compiled form. There is an extension for ADODb as well but you have to install it in PHP first. This is a strong argument in favour of PDO because products based on it are likely to run faster in more environments.
ADOdb supports a larger number of databases than PDO.
Well, I think it boils down to preference. ADOdb is more geared towards people who are used to the Microsoft style of Database access (ADO) and PDO is more "PHP" like and also part of the mainstream of PHP versus ADOdb which sort of sits off to the side.
At the end of the day, it would based on what your target DB is (ADOdb supports more) and what sort of language style your prefer. Personally, I like PDO and it suits my needs.
PDO is native and pretty fast.
ADOdb is a richer library and even has things like ORM (Object Relational Mapping).
For me the big downside of PDO is it's horrible to debug when it goes wrong as there's no PHP source for it. When I was debugging some complicated code the only way I could see the exact SQL that was being executed was the subclass the PDO driver itself...
It's all opinion though of course!
I am developing a big application using PHP. Is MySQL or SQL Server the best one to use?
Neither. Use PostgreSQL. :)
Honestly though, PostgreSQL scales much better than MySQL. I don't know what you mean by "enterprise", but I figure scaling is important for a "big" web application, as you put it, and PostgreSQL does that very well. MySQL can't handle too many concurrent connections. (Though if that isn't an issue for you, go with MySQL for ease of use.)
MySQL and PHP work well together. I'd recommend that combination.
I'd much rather choose an open-source solution rather than rely on MS. That said, you can go with PostgreSQL as well if you need to, or your requirements gear you toward it. We would need more details to know what you truly require.
While this is a bit subjective, I would suggest going with MySQL.
The reason I say this is because traditionally you see people go with a LAMP setup. LAMP of course being Linux + Apache + MySQL + PHP
PHP has some great build in functionality for dealing with MySQL Databases, therefore it may be easier for you. Then you'll also have the ability to do some web based work with PhpMyAdmin tying a web interface to your Database
Use the one you and your team has most experience in terms of both development and administration.
If you start from scratch, I would go with PostgreSQL.
Between your choices I would go for SQL Server, especially if you are working in Windows environment.
It will depend on your application's needs. I'm not especially well researched on the differences between the various SQL engines, but as far as I know, MySQL is faster for SELECT queries (if you have a predominantly read-only type app). On the other hand, MSSQL and PostgreSQL both have better support for transactions, and perhaps also better performance if you have lots of inserts/updates happening. Also, MSSQL and PostgreSQL are said to scale better, but there are various successful applications that seem to do fine with MySQL (Facebook and Flickr as examples).
MySQL and SQL Server Express are free for production use. In my view the best advice is to try them both and decide for yourself. A lot of folks can live quite happily with a lightweight RDBMS where solutions like MySQL/Express may be appropriate.
From a purely technical point of view all of the major RDBMS vendors (Oracle, Sybase, DB2, SQL Server et al.) are significantly more capable than MySQL is currently or can reasonably be expected to be in the foreseeable future.
This does not mean you should not use MySQL for a particular job. A good analogy is continuing to use a version of Microsoft office released years ago. For most people the old version does everything they would ever want even though the newer version is "better" and has more features.
MySQL is certainly better to work with PHP. But MS is putting a huge effort in better supporting PHP on Windows platforms.
SQL Server is DEFINITELY the better choice for large enterprise solutions since there's better cluster and management support. We use MySQL for cost reasons, but i would really like some easier management and cluster support.
On the other hand it's like with computers: many features you need to compare if they suit your needs - and your purse.
If you are doing a one-man-show: Step away from SQL Server. It is only suitable for enterprises. Take MySQL or PostgreSQL.
For most IT directors a big decision is going to be which can you get the best support for in your area / online / already have in-house and which can you get the most uptime for. Ongoing costs are usually higher than deployment costs so its probably not worth worrying about license costs; unless you are into ia64 or better type systems anyway when the CPU count starts to make SQL look eye-wateringly expensive.
It's like deciding what computer to get, they are by now pretty much the same no matter what brand you pick. It's pretty much the same for databases, they all support most of the things that you need for lightweight webapplications.
I have used MySQL to all my php applications so far and had no problems whatsoever. I have wanted to test out PostgreSQL several times but never got to it, but I have heard very good things about it. I never touch MS products however, so no opinion (Not that I am allergic, I'm just stingy.).
I want to benchmark PHP vs Pylons. I want my comparison of both to be as even as possible, so here is what I came up with:
PHP 5.1.6 with APC, using a smarty template connecting to a MySQL database
Python 2.6.1, using Pylons with a mako template connecting the the same MySQL database
Is there anything that I should change in that setup to make it a more fair comparison?
I'm going to run it on a spare server that has almost no activity, 2G of ram and 4 cores.
Any suggestions of how I should or shouldn't benchmark them? I plan on using ab to do the actual benchmarking.
Related
Which is faster, python webpages or php webpages?
If you're not using an ORM in PHP you should not use the SQLAlchemy ORM or SQL-Expression language either but use raw SQL commands. If you're using APC you should make sure that Python has write privileges to the folder your application is in, or that the .py files are precompiled.
Also if you're using the smarty cache consider enabling the Mako cache as well for fairness sake.
However there is a catch: the Python MySQL adapter is incredible bad. For the database connections you will probably notice either slow performance (if SQLAlchemy performs the unicode decoding for itself) or it leaks memory (if the MySQL adapter does that).
Both issues you don't have with PHP because there is no unicode support. So for total fairness you would have to disable unicode in the database connection (which however is an incredible bad idea).
So: there doesn't seem to be a fair way to compare PHP and Pylons :)
your PHP version is out of date, PHP has been in the 5.2.x area for awhile and while there are not massive improvements, there are enough changes that I would say to test anything older is an unfair comparison.
PHP 5.3 is on the verge of becomming final and you should include that in your benchmarks as there are massive improvements to PHP 5.x as well as being the last version of 5.x, if you really want to split hairs PHP 6 is also in alpha/beta and that's a heavy overhaul also.
Comparing totally different languages can be interesting but don't forget you are comparing apples to oranges, and the biggest bottleneck in any 2/3/N-Tier app is waiting on I/O. So the biggest factor is your database speed, comparing PHP vs Python VS ASP.Net purely on speed is pointless as all 3 of them will execute in less than 1 second but yet you can easily wait 2-3 seconds on your database query, depending on your hardware and what you are doing.
If you are worried what is faster, you're taking the absolute wrong approach to choosing a platform. There are more important issues, such as (not in order):
a. How easily can I find skilled devs in that platform
b. How much do those skilled devs cost
c. How much ROI does the language offer
d. How feature rich is the language
I've dabbled with MySQL and personally, I find it vastly inferior to better RDBMSs like Postgres; while I admit it's come a long way and improved, even the latest version to my knowledge does not even support CHECK constraints to verify data integrity (it allows the keyword but doesn't do anything with it).
As someone who is looking at switching away from Microsoft technologies and into open source, I am appalled by the sheer number of PHP-backed applications that will only work with MySQL as the underlying database. A number of these apps are really good and would save a lot of work in development, but the fact they haven't been abstracted to be database agnostic is usually a deal-killer for me and my technical associates.
So I am curious - I understand why MySQL is so popular and why it's almost always used with PHP, but why do so many PHP-backed sites refuse to be properly developed to allow for other databases, but instead force MySQL when there are much better and more "database-like" options out there? I'm getting increasingly frustrated by these apps that I want to use, but they only work with MySQL and I won't bring myself to use it because personally I find Postgres a much better database, and because I personally feel that your database should enforce it's own constraints instead of doing this only at the code level.
I realize MySQL is popular, and it's not a bad system, but I hate when I find a great application and it'll only work when the database is MySQL because the developers used MySQL-specific modules and/or syntax.
I'm sure its the same reason there's so many ASP.NET stuff that only supports MSSQL. Its the traditional database paired with the language just by convention. Plus using/building database independent solutions is hard and one of those things that "you aint gonna need" when most so many other people follow that convention. When its needed its one of those things that can be "page faulted" in.
If you need to get a php app to use another DB, the php is probably open source, perhaps you can do the work yourself.
Cross-platform support, as long as SQL is concerned, is like a duck.
You know, a duck can walk, can fly and can swim — and does all this equally bad.
It's much better to stick to one platform and develop a well-optimized application, then to try to satisfy everybody, satisfying noboby in fact.
Most PHP developers develop with PHP because it's free, easy to get going, and powerful. All of the same qualities are shared with MySQL, so it's a natural fit.
That being said, many professional developers create data-abstraction layers that would allow them easy integration with other backends. But most projects don't need those types of things.
It's mostly the logical end result of the fact that almost all PHP-capable shared hosting services offer MySQL and only MySQL. The extra work to abstract the database is often deemed unnecessary when almost nobody using the application needs it.
LAMP is an extremely common development stack. Common enough that even people who don't use PHP know what LAMP stands for.
For those who don't know (all 1 of you), LAMP most commonly stands for Linux, Apache, MySQL, and PHP.
I think the key point is exactly what you said, "it's almost always used with PHP". By developing for MySQL, they're maximizing their target audience. Yes, it'd be ideal if they developed it to be able to work with multiple databases, but that can be a fair amount of extra work. Lots of these projects just grow from someone's personal project, which was probably not initially designed to be compatible with multiple engines. Once they're pretty far in, it starts to turn into a major job to rewrite the code to support multiple database systems, and there's usually other features/fixes that their users would rather have.
I also greatly prefer pgsql, but I think if you're planning to use other peoples' PHP applications (forums, blogs, etc), it's just a reality that you're probably going to have to run MySQL to support them.
Back in old times there was a huge difference in the ease of use. MySQL was easy to use and very fast for simple task. Back then it didn't provide full ACID, nor triggers, nor subselects, nor procedures. On the other hand you had PostgreSQL (called Postgres back then), which was much slower, complicated to install and mantain, but provided full power of real RDBMS. The thing is, that the web apps didn't really need full power of RDBMS, so MySQL gained huge popularity, while PostgreSQL was used by few.
Ah, one more thing: as of PHP5 SQLite comes embedded. So I expect that pretty soon a lot of new PHP apps that don't really need full blown RDBMS will use SQLite, rather than MySQL.
You're right, PostgreSQL has much better support for SQL and other advanced features, so there's a very good case for why PostgreSQL is superior to MySQL.
However, MySQL is so much easier to install and manage for someone who is just getting started, that it gains a lot of adoption relative to PostgreSQL. Simple tasks like configuring a login and giving it specific privileges are very confusing on a PostgreSQL server, compared to MySQL.
Also, there were a few years early on where MySQL offered native binaries for Windows but PostgreSQL did not. You could get it to work under Cygwin, but that's hardly satisfying for a real Windows developer. By the time PostgreSQL did support Windows natively, MySQL had a substantial lead in market share and name recognition.
BTW: http://www.postgresql.org/support/professional_hosting_northamerica
IMO the big problem with so many MySQL-only sites is that MySQL doesn't support half the features of a "real" database, so if you need data integrity you're pretty much screwed and will have to write your own software instead of taking advantage of existing solutions, or compromise your application and don't have any real integrity checks at the database level. You end up between a rock and a hard place.
We're wanting our cake and eating it too with this question. First, we want database abstraction. Then, we want CHECK constraints in the RDBMS we choose to use behind that abstraction.
Huh? That means we'll neglect to do data checking in the PHP itself, and things will break using databases without the CHECKs. Either that or we WILL implement the checks in PHP to support an abstracted database without CHECKs, doing twice the work.
I think full database abstraction isn't worth the effort, and is mostly a solution in search of a problem.