I run a website that uses a database, but not intensively, on a WAMP configuration. I currently use MS Access: We have a small database, < 4MB max, that can be downloaded for easy backup and emailed to organization members for completing tasks in the MS Access software (like generating reports, etc.). However, it requires MS Office software and isn't exactly standard use with PHP.
On the other hand, our host provides MySQL, which is typical with PHP, generally more powerful, has a greater availability of software and support, but backup can be a little messier.
But, MySQL is not hosted on the local host. So, I copied the information to MySQL, and made a copy of the site using the MySQL database. I proceeded to run some benchmarks, and surprisingly, MS Access was faster, marginally.
I am not sure which is the best direction to take at this point. Hoping the community can give some pros and cons that I haven't though about.
Since Access is way simpler, it's not surprising that rough benchmarking reveals it's faster. The difference comes when you have to deal with concurrent sessions and large data sets. Desktop apps are normally used by a single process at a time but in web applications concurrent queries are the norm.
Said that, if you've been using Access for a while and you didn't find issues, I don't think that switching to MySQL is going to make any difference regarding performance. I'd think about other considerations:
Would you like to have Linux hosting as an option?
Are you proficient enough with MySQL as to migrate code in a reasonable timespan and with reasonable quality?
Can you replace those reports with plain HTML listings?
BTW, MySQL backups can be automated with a simple command line script, it should not be messy at all.
One pro that MS Access is already offering you is a client interface. You've mentioned users that are "generating reports, etc.". Unless you already have an alternative in place that will do everything they need, switching to MySQL will likely be a no-win situation.
I'd stick with Access database for such a small scale project! There's no need to move onto a bigger technology for the hell of it - put it this way, if you had 4 kids, and a bus came up for sale, would you buy the bus because you can fit your 4 kids in it?
One big advantage of MySQL IMO is that PHP has built in support for MySQL. You can use ODBC with PHP to connect to MS Access but it's one more thing to set up and one more thing to 'break' at some point.
Could you set up MySQL on the host? Is it likely that your database would grow and become more complex in the near future?
Access is ideal for us: several accountants using it in our accounting work in the same room but not through the internet, and none of us is programmer. The only thing to think about is the fee for Access copy-wright.
Mysql is free, yes, that is great, but Mysql lacks stored queries, forms and reports, and the quick "on_click, on_doubleclick..." functions that are extremely useful and easy to handle in Access. Are there ways to solve this problem. Thank you.
Related
I find myself in a situation that someone else must have got stuck in at some point.
Our company runs an in house MSSQL based database, our website then sits on an external server and currently runs MySQL. The problem comes that both databases need to communicate with each other increasingly often.
Our current solution involves SSIS packages but they are tempromental and often slow. We end up very often having to drop tables on our live production server before then rebuilding them from the in house server. Of course this is leading to data inconsistencies so we try and perform these operations outside of peak hours. However, this leads to 24hr delays in some data being transferred from MySQL to MSSQL and then an additional 24hr delay in getting it back to MySQL. None of this is ideal.
What I am looking for is a solution that will allow replication between our in-house MSSQL server and any database that can sit upon a linux box and play nicely with PHP. As I said, we currently run MySQL so we have a preference to any solution that would include that but all other suggestions would be greatfully received.
I've read somewhere that PostgreSQL is a vialbe solution but I am now struggling to find where I read that. I've come accross a few tools that might help such as DBMoto and Slony-I, does anyone have any experience of either in such a situation?
Alternatively, are we simply barking up the wrong tree altogether and should we be trying to integrate MSSQL into our PHP environment?
Any thoughts or suggestions would be gratefully recieved.
Many thanks
Rob
The best solution that i know and i have used for this kind of job is SymmetricDS .
SymmetricDS is an asynchronous data replication software package that
supports multiple subscribers and bi-directional synchronization.
You can access MSSQL servers from PHP using FreeTDS and the mssql_* family of functions (or classes built thereon, or alternative freetds-using extensions). We use this for our admin application, with a Linux/PHP website talking to a MSSQL database.
We have been using PHP/MySQL for our web application which has been growing a lot, the database is around 4-5GB and one of the table is 2GB sometimes, hence slowing down whenever any queries to that table is called.
Should we just try to optimize, or are we using MySQL above its limit? Will switching our web app to .NET/SQL Server resolve the issues?
You're going to get a lot of very passionate responses to this.
PHP is, from a code and performance standpoint, very similar to classic ASP. ASP.NET v1 was , according to many, many benchmarks available via your favorite search engine, 3x-5x faster than classic ASP. Draw your own conclusions.
I feel that MSSQL is a superior database solution. If you're stuck with open source, at least look at Postgres. It's less popular but very powerful.
To answer your real question: performance is a function of your toolset and platform choice, but also of developer skill and project structure. I've seen far more projects that could benefit from some healthy refactoring and optimization than I have that are limited by the platform in which they are written. It is rarely worthwhile to rewrite a large application in a completely different language. Instead, I would focus on improving your existing codebase, and looking for ways to incrementally upgrade to a platform like ASP.NET.
Also keep in mind that switching will require you to jump to IIS Windows server and there will be more cost involved most likely. There are a lot of considerations here when thinking about a switch like this.
I say if the application calls for it, work it out.
You certainly aren't using MySQL above it's limit. But you should consider benchmarking your database queries on MSSQL to see if you notice a huge improvement.
There are many factors involved here, your code base, database optimisations & changes to table structure, server spec.... they all contribute independently.
Are there any particularly slow queries or is it running slow accross the application? Can any caching be implemented here? Do you have propper indexes?
I am planning to build a web app running on a single computer and exploit the hardware resources as efficient as possible. The logic of app will not be complex. The following is my design:
OS: Linux (CentOS 5)
Web Server: Nginx
Web script: PHP
Database: Tokyo cabinet + Tokyo Tyrant
Index: Sphinx
I am not going to use RDBMS such as MySQL, cause I think a key-value store (Tokyo cabinet) with a indexer (Sphinx) will meet all the needs to deploy a normal web app, also with better performance than MySQL.
My question is: is this design to be the an efficient architecture for a single computer? Or how to improve it?
(I know this question might to be subjective but I really need your help)
Thank you very much~
EDIT:
The computer I am going to host my app on, is a normal PC, like 8GB~16GB memory, 500G~1TB Hard disk, etc. I think it won't need to consider the "scalability". Every first step of a web app is started from one machine and it will always the beginning.
Choice of DB
I think that the choice of type of database you make depends less on how many computers the system is hosted on. I think this should be more a function of the quality of data that you want/need to preserve.
For example, if you need to store the shipping addresses for a customer, you will need to account for that in your storage structure. A name value pair may seem an easy enough structure to begin with, but if you foresee any of the following, you should consider moving to a standard database system
keeping track of changes
reporting activity / reports
concurrent users
Performance
This is dependent on your code, images, content, caching, etc just as much as it is on your database.
well, one way to see is to load test it:
http://grinder.sourceforge.net/
I've never worked with Tokyo cabinet, but if it's functionally sufficient, then it will probably be significantly faster then a DB.
In the long run though, any savings you realize by tuning your app to work on one box will be quickly lost when you start to scale beyond that box. trying to add a lot of caching, and hacks to get the app to be faster will only go so far. More importantly you should try to think about how easily you can decouple the various layers.
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'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.