I am new to Ruby and wondering if most people are using the SQLLite db that seems to be the most natural and recommended db to use with Ruby? Or are people using the traditional MySQL db?
What are the benefits/drawbacks of each with Ruby?
Thanks,
Alex
SQLite is used primarily for development purposes only because it is quite simple to setup a database without much frustration, however it is certainly less efficient in terms of concurrency (which is highly likely for web applications) than something like MySQL. So regardless if you use SQLLite in development or not, it is highly advisable to use MySQL (or something equivalent) in production.
For completeness sake, SQLite is also used in "all in one package" software (such as mobile development), in which you can easily bundle a SQLite file with your application.
As stated on SQLite Website:
SQLite is not intended to be an
enterprise database engine. It is not
designed to compete with Oracle or
PostgreSQL.
and
Another way to look at SQLite is this:
SQLite is not designed to replace
Oracle. It is designed to replace
fopen().
In terms of the benefits with Ruby, there really isn't much benefit as libraries/ORMs (i.e. Active Record) really abstract the differences between the two systems to make a consistent access layer in a single wrapper.
SQLITE is cool for desktop applications, mobile applications, and for development :) because it is easy to install and to manage, also it stores all data in one file, which is easy to copy.
But it is a bad choice for production. It doesn't support parallel acces for writing. As bigger file, as slower queries. Problems with scaling. And a number of other problems.
See this topic for more information
https://stackoverflow.com/questions/3630/sqlite-vs-mysql
In rails, you are using ActiveRecord ORM. Many developers are using sqlite adapter for development with ActiveRecord, because it is very easy to setup it.
Related
We have a built a new data fusion C++ algorithm which uses SQLite as an internal database.
However, we would like each of the multiple C++ threads to do a parallel db write and SQLite cannot do that.
So we are now looking at MySQL which allows each of the multiple C++ threads to do a parallel db write.
However, the MySQL non-GPL licence is too costly and we don't want to rely on Oracle for MySQL support since our data fusion C++ algorithm will soon have a US patent.
Are they are any alternatives to MySQL which allows each of the multiple C++ threads to do a parallel relational database write which do not have a costly licensing policy like ORACLE MySQL?
So far, I am starting to look at PostgreSQL's BSD license and Sybase open source relational database.
Could someone tell us if PostgreSQL or SYbase is the right direction to go in?
PostgreSQL is definitely a very good alternative to MySQL.
In my opinion PostgreSQL is actually the better choice anyway looking at all the things that MySQL doesn't get right and the number of SQL features that they still don't have.
But again that's my personal opinion.
In terms of licensing the Postgres license is indeed more flexible for commercial usage than the GPL.
The support from the PostgreSQL community on the mailing list is outstanding - I don't know if there is something comparable in the Sybase world (actually I didn't know that Sybase is now OpenSource).
There should be quite a few options. If you're not worried about being cross platform, you could try SQL Server Express. You can use this in production subject to some limitations (I think the limit relates to the type of hardware you can install it on). There is also an express edition of Oracle with similar usage constraints.
In the open source world, there is Firebird which I believe you should be able to use in embedded mode (that is, without having to install a separate network server process). I haven't used this in production but it has been around for many years and looking through SO, it seems to be well regarded. It uses MPL so there should be no licensing risks.
For completeness, you could consider MaxDB from SAP and the Ingres Database System. MaxDB seems to be a very capable DBMS but when I tried it years ago (version 7.6) it seemed to be extrodinarily difficult to work with. I've never worked with (or heard of anyone working with) Ingres but apparently it's open source and can be freely used.
Like "a_horse_with_no_name", I'm not aware of there being an open source edition of Sybase although I might have just missed it.
Phil
I'm building a web application right now for my company and for whatever reason, can't get mySQL working on my Mac w/ my Ruby install (OSX 10.5). SQLite works fine though, so would it be a problem to use SQLite for now so I can get to work on this and then just change up my database.yml file to point to a mySQL database when I deploy (assuming I rerun migrations and such)?
Also, what are the benefits/drawbacks of using mySQL over SQLite in a RoR application? I've always used mySQL by default in the past, but never learned SQL directly (always through ActiveRecord) and never thought too much about the difference.
Benefits of MySQL/PostrgreSQL/etc
Pros
Stronger data typing, which means cleaner data
Ability to store more data
Scale better to larger data sets
Spatial support (think GPS)
Full Text Search (FTS)
Cons
Stronger data typing means data will be validated, bad data will cause errors
Not a good candidate (if even possible) for devices with limited resources (iPhone, Blackberry, iPad, etc)
I would pick PostgreSQL v8.4+ over MySQL given the choice. MySQL's features lag behind the rest of the major SQL database alternatives.
THe biggest performance issue you may run into is table locks. SQLite unfortunately does not have row level locking. So if your app is going to run multiple processes / threads (as with multiple web users) its likely some threads will not be able to perform an SQL op. For this reason i would go with MySQL - or perhaps Postgresql.
Should be no problems, as MySQL should have a superset of SQLite capabilities, and as #Sean pointed out, performance should only increase. Just try to make sure you're not using anything too SQLite specific (I'm mainly a SQL Server and Oracle guy, so don't know what that would be, if anything). Remember, the "S" in SQL stands for Structured, not Standard ;)
Paul.
SQLite is perfect for a desktop or smartphone application ("embedded" usage). However, if you plan to build a web-application, you are highly encouraged to make use of a non-embedded DMS like MySQL. The benefits are countless, such as 3rd party design and analysis apps, performance etc ...
I am developing a Rails application that will access a lot of RSS feeds or crawl sites for data (mostly news). It will be something like Google News but with a different approach, so I'll store a lot of news (or news summaries), classify them in different categories and use ranking and recommendation techniques.
Should I go with MySQL?
Is it worthwhile using IBM DB2
purexml to store the doucuments?
Also Ruby search implementations
(Ferret, Ultrasphinx and others) are
not needed If I choose DB2. Is that correct?
What are the advantages of
PostreSQL in this?
Does it makes sense to use Couch DB in
this scenario?
I'd like to choose the best option but without over-complicating the solution. So I discarded the idea to use two different storage solutions (one for the news documents and other for the rest of the data). I'm also considering only "free" options, so I didn't look at Oracle or MS SQL Server.
purexml is heavier than SQL, so you pay more for your roundtrip between webserver and DB. If you plan to have lots of users, I'd avoid it, your better off letting your webserver cache the requests, thus avoiding creating xml(rss) everytime, if that is what you are thinking about.
I'd go with MySQL because its really good at serving and its totally free, well PostgreSQL is too, but haven't used it so I can't say.
CouchDB could make sense, but not if you plan on doing OLAP (Offline Analysis) of your data, a normal RDBMS will be better at it.
Admitting firstly that I generally don't like mysql, I will say that there has been writing on this topic regarding postgres:
http://oldmoe.blogspot.com/2008/08/101-reasons-why-postgresql-is-better.html
This is always my choice when I need a pure relational database. I don't know whether a document database would be more appropriate for your application without knowing more about it. It does sound like it's something you should at least investigate.
MySQL is probably one of the best options out there; light, easy to install and maintain, multiplatform and free. On top of that there are some good free client tools.
Something to think about; because of the nature of your system you will probably have some tables that will grow quite a lot very quickly so you might want to think about performance.
Thus, MySQL supports vertical partitioning but only from V 5.1.
It sounds to me the application you will build can easily become a large-scale web app. I would suggest PostgreSQL, for it has been known for its reliability.
You can check out the following link -- Bob Ippolito from MochiMedia tells us why they ditched MySQL for PostgreSQL. Although the posts are more than 3 years old, the issues MySQL 5.1 has recently tend to prove that they are still relevant.
http://bob.pythonmac.org/archives/category/sql/mysql/
MySQL is good in production. I haven't used PostgreSQL for rails, but it's a good solution as well.
In the dev and test environments I'd start out with SQLite (default), and perhaps migrate to your target DB in the test environment as you move closer to completion.
Someone asked me this the other day, and I couldn't think of a good answer. Platform portability is completely irrelevant to the project.
In fact, Jet has some features that SQLite does not, namely foreign keys.
So can anyone think why SQLite should be used instead of a Jet database?
Contrary to what other people are saying, Jet is not dead and far from it: ACE is the new version of Jet and it's pretty robust and backward compatible.
Both SQLite and Jet/ACE have their strengths and weaknesses and you need to get more information about the specific points that are important to you and your application.
In either case you can redistribute the engine.
Jet/ACE is a bit more integrated and supported out of the box in MS tools and Visual Studio.
Jet/ACE has more granular locking, which may be important if your app allows multi-users or needs multi-threaded access to the database.
Jet/ACE has more features in terms of what you would expect from a database (joins, unions and complex queries).
Jet/ACE has a simple migration path to SQL Server, so if your database needs become big, you could move to SQL Server fairly easily.
SQLite is cross-platform, so if your app needs to be ported to Linux/Mac under Mono then SQLite is a better choice.
the SQLite engine is tighter so redistributing may be easier.
datatypes are quite loose in SQLite.
SQLite has more liberal redistribution rights (since you can basically do whatever you want with it).
People who say that Jet corrupts databases are stuck in 1995.
In the end, unless your application has some very specific requirements that are pushing the boundaries of either database engines, then it probably doesn't matter which one you chose.
Just use the one that easiest for you to include in your project.
SQLite is superior to Jet for the major reason that SQLite is ACID-compliant whereas Jet, unfortunately, isn't. If data integrity is an issue, SQLite offers a much more "robust" platform for your data storage requirements. See "SQLite Is Transactional" and "Atomic Commit In SQLite" for more details.
SQLite does indeed lack a few features (such as foreign keys), however, these are primarily due to SQLite being specifically developed as being an extremely small and lightweight database that is also serverless.
The serverless aspect of SQLite is also a major benefit over Jet in that nothing needs to be installed on the machine that will run your database. For example, I have used SQLite in an ASP.NET web application and all I needed was the SQLite DLL (in this case is was the excellent System.Data.SQLite drop-in replacement) in my application's "bin" folder, and my database in the application's "App_Data" folder. I could then upload these files to my webhost, and it all "just worked". This is without having to actually install or register anything on the target machine.
A small dowside of SQLite is due to the database being file-based. Database writes will lock the entire database file rather than a specific row or table, whereas Jet will offer you a more granular level of locking. Another small issue, based on the same file-based reasoning, is concurrency, however Jet itself does not offer a high level of concurrency either.
This is still a question that comes up from time to time. I'm considering all the pros and cons for both right now for a new project. I write a lot of financial applications that deal with money values so one of the most important "pros" for Access/JET/ACE/whatever-they're-calling-it-today (I just call it Access) is its strong types. Don't underestimate the power of having strong types when you're dealing with money - Access is the only single-file database I've seen with support for a money/decimal type that can store REAL money values.
One of my main retail products uses SQLite as a backend and I can tell you that I've had virtually no problems with it deployed even in the craziest situations. SQLite is definitely designed to be single-user but I have a LOT of customers using it over SMB. You do have to write checks into your software to check for return values of SQLITE_BUSY when running queries but if you wrap that up with an auto-retry it "just works".
There are only a few reasons I'd choose Access over SQLite - one is data types. If I'm ever writing software that has to do math on money values (tax, etc), I'll use Access. The only other compelling reason to use Access is an upgrade path to SQL Server. Since I've never used SQL server in my life (and don't plan to), it's not a big deal.
In the end, both are extremely robust databases - I wouldn't hesitate to use either in a production environment. Just remember to use the right tool for the job and sometimes that means a database server (PostgreSQL has treated me right over the last 13 years, that's for sure!).
We used Jet for a long time and recently switched over to SQLite. Why?
1: When a database gets anywhere near 2 GB or with frequent use, it becomes corrupted in Jet eventually. This has caused us a lot of grief! This has not been fixed in Jet or ACE, though Microsoft has a separate tool that can supposedly fix the database files.
2: Microsoft deprecated Jet years ago, in favor of ACE, but if you read the details, Microsoft itself says that ACE is NOT a replacement for jet, and really wants you to use SQL Server instead.
3: Jet is no longer a standard part of Windows, but part of Microsoft Office, though you can download and install the distributable. However, you can not have both the 32 and 64-bit engines installed at the same time. If you have Office 2007 32-bit installed, and you try and install the 64-bit ACE engine, it tells you need to uninstall Office 2007 first.
So for these reasons we just decided enough is enough. Installing SQL Server is not a solution because it is a big complex invasive install and not very portable.
Our C++ software directly supports SQLite via the sqlite3.c file, and it works very well. I have implemented antive interfaces for OCILIB, Oracle, SQL Server, MySQL etc and this was one of the easiest. It is also much faster than Jet and the resulting files maybe a third of the Jet size. We do have some VB6 and VBA and .NET code that also need to use our database files and for that we use the SQLite ODBC driver (just Google it). Works well.
SQLite works fine in both 32 and 64-bits. And if you read up on it you will see it is seriously tested and amazingly stable. It also supports more standard SQL and is closer to Oracle/SQL Server than Jet is.
Jet is no longer supported. SQLite is also easier to install since it's one dll that can easily be packaged with your app. Using SQLite also can prevent vender lockin, just because language or cross platform portibility isn't a concern now doesn't mean it won't become one later. For more on Jet's retirement see
http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
Cost is not an issue. If your frontend is built in something other than MS-Access, users of the application do not have to pay any fees to have the Jet drivers installed. Visual Studio would include those drivers during your build (At least the pre .NET versions did.).
I'm guessing you have no personal preference and are equally skilled in development in either environment. If your users have already MS-Access licenses and they would like to be able to write their own reports (Oh, God forbid any non-hacker attempting such a tremendous feat!), use Jet.
SQLite is the new Jet. Even if cross-platform is irrelevant to you, it may not be to your customers. Using Jet locks them into Windows and to a no longer supported DB, neither of which are good things. And SQLite works with just about any development environment out there.
Jet is known for having strange corruption issues, so I tend to stay away from it in general.
You can certainly create foreign keys in SQLite, and as of SQLite 3.6.19 foreign key constraints have also been added.
Off the top of my head, it's free and cross platform; but more important... do you think it is more stable and scalable that Jet/MS Access/.mdb? Will it be longer lived that its successor (ACE/.accdb)
If it is being used by more than just a couple people, I don't bother with Jet. I go straight to MS-SQL (even the free version of it). It's just not worth the pain of a corrupt DB (which Jet is known for - although maybe they fixed it - I don't want to be their test case though).
If you program well in Python, Pearl, Lua or many other languages, SQLite would be the natural choice.
I've used both and I've found MySql to have several frustrating bugs, limited support for: IDE integration, profiling, integration services, reporting, and even lack of a decent manager. Total cost of ownership of MSSQL Server is touted to be less than MySQL too (.net environment), but maintaining an open mind could someone point out any killer features of MySql?
I've used MySQL in the past and I'm using MSSQL lately but I can't remember anything that MySQL has and MSSQL can't do.
I think the most killer feature of MySQL it's the simplicity. For some projects you just don't need all the power you can have with a huge system like MSSQL. I have an UNIX heritage and find the simple configuration file like my.ini a killer feature of MySQL.
Also the security system of MySQL is much less robust but it makes the job right for most of applications. I believe MySQL it's killer itself from this point of view, and should stay that way, letting young users being introduced to RDBMS with a simple view first. If your project gets big enough that you are considering switch to a more robust system, then MSSQL can pop as a possibility.
That's what happened to me.
The only thing I can think of, off hand, is locking. SQLServer has traditionally had poor locking strategy that has tripped many people up.
You should use what you prefer, ultimately. Its not as if MySQL is not good enough to compete with MS SQL, eg. Slashdot uses MySQL, so its hardly got problems with high-scalability performance.
Its killer feature though, is that it is free - you can deploy as many of them without worrying one fig about licensing issues. That's more important for the spread of software than anyone could imagine.
(TCO is a difficult thing to calculate - and is advice only ever given from paid consultants and other vested interests. Ignore that. MSSQL is expensive and MySQL is free.)
About 6 years ago I developed a custom e-commernce website using ASP and MySQL for the database. At the time MySQL was clearly a better choice than MSDE which had built in throttling which concerned me enough to use MySQL. Also the difference in coding between using MySQL and MSDE/SQL was not that different or much of a concern.
Now all these years later I'm trying to get the code converted to .NET and even after purchasing commercial MySQL drivers from CRLab. I found that, as you hinted, the IDE integration is just not up to par.
I will say that MySQL is doing a great job even with our database tables approaching 4GB. So when I switch to MSSQL I have to go ahead and get SQL Workstation or higher ($$$), and not use SQL Express which has a 4gb limit.
All of my experience has changed the way I develop new websites. Now, unless it is expected to have a lot of traffic. I use VistaDB and then upgrade to SQL Server if needed. VistaDB is syntax and datasource compatible with SQL Server. And the best part is it is only a single file for the database and a dll for your bin folder.
That's my two cents based on my personal experience with using MySQL in ASP and now .NET.
I work with MSSQL, MySql and PostGres regularly (using .net, java and PHP). One of my favorite things about about MySQL (esp. compared to MSSQL) is the ease with which you can run and restore full database backups.
MSSQL's model of using .bak files is really ugly and time-consuming (topic for another post.) But if you want to do somethign like automated testing, or automated build processes (that include building a db from scratch), MySQL can be a bit easier to deal with.
A few other points:
The management tools have gotten a lot better since the early days.
If you are interested in transactions, constraints, etc.. be sure you are defining your tables to use the InnoDB storage engine (instead of MyISAM which is designed for speed.)
I do miss MSSQL's schema generating tool, but I think there are equivalent tools out there.
We've used a Linux database server and a window's web server (for .net apps) with great success.
If you are using something like NHibernate or some other non-MS data abstraction layer, the case to look beyond MSSQL is stronger too...
Three points to consider; unfortunately the first two are contradictory:
1) .NET and MySQL were not designed to interact with one another, and there is no official support from either side. You're invariably going to encounter issues trying to use them together.
2) If portability off of Windows may ever be an issue (much .NET code runs quite nicely on other platforms via Mono), you'll want to avoid locking yourself too deeply to MSSQL. That doesn't mean not using it, but being careful that you don't rely on its particular quirks too much.
3) TCO is just a buzzword. It's complete nonsense when it's calculated by anyone other than you. Nobody can make such a calculation and honestly claim that it has any relevance outside their particular environment. There are too many factors, most of which have absolutely nothing to do with things like tool availability.
I've been using the community version of MySQL for alsmost 99% of my project. I like MySQL is that I can deploy via Xcopy and is powerful compare to other "xcopy-able" database server. I also wrote a wrapper to start and stop MySQL & Apache (like LAMP), but with my own implemetation and addon capability
MySQL probably has a lower TCO, since administration and configuration is more simple and straightforward than the Spaghetti GUI that MS SQL makes you do most of the configuration through, having to dig through hundreds of obscure properties dialogs to accomplish even basic administration tasks.
There is one area where MS SQL clearly excels over MySQL in my experience:
Integration with other technologies. MS SQL allows you to replicate back and forth with Oracle and MySQL databases, and provides SSIS for executing scheduled data transformations from other database servers.
There may be others, but I don't have experience with them.