I'm getting into MVC and is wonderful, however, still need to decide what dabatase system to use. For many years my options have been:
1) MS SQL. For complex web applications. Example: A shopping cart or CMS.
2) MS Access. For smaller and simple ones. Example: a small product catalog, blog or news system.
I don't want to keep using Access, however, using SQL means using SQL Express if you don't want to pay more (my clients will not want) in SQL database hosting. But using SQL Express (when hosting supports it) get some some connection problems when many connections are opened (from your app and others hosted apps in the same pool).
I want to use LINQ, thats why now I'm forced to use MS SQL (express) in order to use LINQ2SQL.
Any suggestion on what database rather that MS Access or SQL Express can be used that doesn't require more hosting expenses? Otherwise I have to try Entities + MS Access. Thanks for your help.
Access is completely unacceptable for any website that expects to handle more than one user at a time.
http://www.15seconds.com/Issue/010514.htm
What are your requirements for the databse? Do you need it to be relational? How many simultaneous users are you expecting for your website?
I would either use MySQL or SQL Server Express.
Perhaps you can post the details of your SQL Server problem. We may be able to find a fix for it.
For most small to medium websites, I would definitely use SQL Express. Its free and within its remit, works just as well as SQL Server full version. We run innumerable websites with SQL Express.
Regarding Access, Access is no joke. It just depends how you use it. If I put #mattimus on a horse and told him to lasso a 450 kg cow (something I did on a daily basis as a kid), he too would be a joke. It's horses for courses, isn't it?
To dispell the Access misconceptions, that are based on ignorance and false snobbery, see:
Who Access really is (one very versatile cookie for a start)
Just don't use Access for a website. You don't need to. SQL Express is all you need.
You can use pretty much any database that you want with MVC. As other have suggested stay away from Access for web development.
SQL Server including the Express edition is a good candidate for small web sites. You can also look into MySQL and other cheap/free relational databases.
On an unrelated note, mi familia es de Merida Yucatan. :)
Like so many questions asked on SO, this one is like "how long is a piece of string?" You can't say really say what's appropriate except if you consider the environment.
For a read-only website, Jet/ACE can perform quite splendidly if you know what you're doing. Michael Kaplan's http://trigeminal.com is backed by a Jet database, but it's read-only. Back in its heyday, MichKa used to say he was getting 100K pageviews per day (or some number that was outrageously high, so far as I was concerned!).
But with a read/write site, you wouldn't be able to support nearly as many users.
That doesn't mean you could use Jet/ACE as the back end. If you have five users max, and it's an Intraweb app, you can be just fine with it.
I wouldn't want to use it myself, but it's not going to be a problem with user populations that are appropriate for the Jet/ACE database engine to begin with, and particularly if you manage your connections properly. Jet/ACE works better with a single shared connection than it does with constant opening and closing of connections (because of the overhead of creating and recreating the LDB file), so you have to code against it differently than you would with your standard server-based database.
Also, Michael Kaplan used to point out that via ADO/OLEDB, Jet was threadsafe, but via DAO, it was not. Use of ADO/OLEDB made it marginally acceptable as a back end for a web site, though I would tend not to choose it for anything other than a site that was very small or disposable, or where there were no options that were not outrageously expensive.
But the key point is that there is no blanket statement that can be made here -- whether it will work reliably depends entirely on the specifics of the environment in which you're using it.
Access is a joke. You should go with MSSQL, MySQL, or Oracle. I like MSSQL personally. Access is not designed to handle large operations and is ridiculously slow.
Related
My friend has setting up a database for a Ragnarok Online server, and he wants me to code the relative website, which is going to use some of that data (and obviously, i'll have to add tables for the news system, website accounts, etc). Since i'm learning RoR i was going to do it that way.
I have a few "best practice" questions related to this :
Should I create a different database for the website, since it's going to have its particular data alongside the game data ? (i already have a few clues to link multiple databases with Rails, but that seems too much of a hassle for what it is).
If not, do i have to create Model/Controller for each of the tables composing the database, despite the fact that i'm not going to use 90% of it ? Or just the ones that i need ?
An example of this problem : the game database has its own "user" table, but i have to have another "user" table for the website, and do some Joins between those two. So, what's the best practice here ?
Uhm, best practice is not making your own user table. This will cause you much pain. Best practice? Use an API. Expose the game's database in some way to your website, and fetch that info with external requests in your web application.
The reason why making a second user table is a hassle:
1) You'll constantly have to update it, pulling data from the original
to keep it up-to-date.
And I mean furthermore, you're gonna have to create a CRON job or something pulling data from that original table to keep it up to date. Yuck. Also what if that CRON job makes a mistake? (It will)
2) It's almost inevitable that there will be inconsistencies if two
separate tables are maintained. Are you sure your web application is
really fail-proof?
Update:
What you're gonna need is essentially a second Rails application that acts as a REST API for that database. For a good idea of what REST is, I'd read through this to get you started: http://tomayko.com/writings/rest-to-my-wife
Once you have a good understanding of that, start making your app, and test if it's working by using tools like cURL to send requests to your API.
Once you have that done, I'd take a look into the Ruby rest-client gem like Nobita mentioned. This is what you're going to use from your web application to request information from your API application.
Just let me note, I think this would be a terrible first Rails project, unless you're already really well versed in other web development tools, preferably MVC frameworks.
I'm about to finish building a simple subscription based support ticket Web app. I'm setting up authorization. But since this it's going to be my very own Web app that I'm going to deploy I'm wondering about this.
Do you create a separate database per account opened?
Let's say you have this support ticket Web app. You have ONE and ONLY ONE account owner. Account owner can setup agents that can respond to support tickets. Also, there are customer roles that open support tickets.
So as you can see the database will contain users, support tickets and more.
What is the best way to go?
1) Create one database for the whole application? That way every time somebody signs up, everything is added to the same database with the other tickets and users data and everything else or...
2) Everytime someone signs up, create a separate database per account subscription.
I'm thinking that maybe option number 2 would be a best choice for security and data integrity purposes. If so, how have you gone about tackling this issue?
It sounds like what you want is Multitenancy:
Multitenancy refers to a principle in software architecture where a
single instance of the software runs on a server, serving multiple
client organizations (tenants). Multitenancy is contrasted with a
multi-instance architecture where separate software instances (or
hardware systems) are set up for different client organizations. With
a multitenant architecture, a software application is designed to
virtually partition its data and configuration, and each client
organization works with a customized virtual application instance.
- Wikipedia article on Multitenancy
This article while a little dated is the general idea of how I would go about doing it. Simple Rails Multi-Tenancy. It's clean and efficient and saves you from writing code that you don't need to.
You should go for option #1. Number 2 is (almost (there are probably cases where it is good, but I can't find one at the moment)) never an option.
You are right in security purposes (well, in a sense), but it also creates a lot of other problems that you will have to think about.
Having a different database for each user means that for each request (remember, HTTP is state-less) you will have to open up a new connection to the database, do whatever needs to be done and then close the connection again, instead of using the connection pooling that is in Rails. This affects the performance a great deal.
Administration will be a hassle the more databases you have. Also, having multiple databases on a server do require more resources than just a bigger database.
You would have to circumvent the entire connection handling in Rails since there it is usually one database per application. It is easy to change the database for specific models, but it adds additional places where things can go wrong.
Rails do have good functionality for scoping and handling of separating data within the same database, just for that kind of use-case that you are mentioning.
I am trying to build a CMS I can use to host multiple sites. I know I'm going to end up reinventing the wheel a million times with this project, so I'm thinking about extending an existing open source Ruby on Rails CMS to meet my needs.
One of those needs is to be able to run multiple sites, while using only one code-base. That way, when there's an update I want to make, I can update it in one place, and the change is reflected on all of the sites. I think that this will be able to scale by running multiple instances of the application.
I think that I can use the domain/subdomain to determine which data to display. For example, someone goes to subdomain1.mysite.com and the application looks in the database for the content for subdomain1.
The problem I see is with most pre-built CMS solutions, they are only designed to host one site, including the one I want to use. So the database is structured to work with one site. However, I had the idea that I could overcome this by "creating a new database" for each site, then specifying which database to connect to based on the domain/subdomain as I mentioned above.
I'm thinking of hosting this on Heroku, so I'm wondering what my options for this might be. I'm not very familiar with Amazon S3, or Amazon SimpleDB, but I feel like there's some sort of "cloud database" that would make this solution a lot more realistic, than creating a new MySQL database for each site.
What do you think? Am I thinking about this the wrong way? What advice do you have to offer in this area?
I've worked on a Rails app like this, and the way it was done there was named-based virtual hosts, with db entries for each site running. Each record was scoped to a site if necessary (blog posts, etc.) while users would have access to all sites running out of that db. Administrator permissions could be global or scoped to one or more sites.
You're absolutely correct when you say you'll reinvent the wheel a million times during the project. Plugins will likely require hacking on top of the CMS itself.
In my situation, it ended up being a waste of almost a million dollars of company money to build that codebase to run multiple sites while still being able to cater to the whims of each client site. It worked, but was not very maintainable due to the number of site-specific hacks that subsequently entered the codebase. You may be able to make it work if you don't have to worry about catering to specific client sites running on your platform.
In the end, you're going to need a layer of indirection to handle the different sites regardless of methodology. We ended up putting it in the database itself. If you go with the different-db-for-each-site method you mentioned, you'll put that layer in your code instead. I'm not sure which one is the better method.
I hope you're able to pull this off. I failed.
Also, as I learned today, Heroku offers postgres instead of mysql for rails apps.
There's James Stewart's Theme Support Plugin for Rails 2.3, and lucasefe's themes_for_rails gem for Rails 3+.
I just started using the 2.3 version and it's working well so far.
I was wondering if somebody has some insight on this issue.
A little background:
We've been using Rails to migrate from an old dBase and Visual Basic based system
to build internal company IntrAnet that does things like label printing,
invetory control, shipping, etc - basically an ERP
The Dilemma
Right now we need to replace an old customer-facing website that was done in Java, that
would connect to our internal system for our clients to use. We want to be able to pull information like inventory, order placement, account statements from our internal system and expose it to site live. The reason is that we take orders on the website, through fax & phone and sometimes we have walk-ins. So sometimes (very rarely thou) even a short delay in inventory update on our old Java site causes us to put an order on backorder, because we sell the same item to 2 customers within half an hour. It's usually fixed within one day but we want to avoid this in the future.
Actual Question
Does anyone have any suggestion on how to accomplish this in a better
way?
Here are three options that I see:
a) Build a separate Rails app on a web server, that will connect to the same DB that our internal app connects to.
+++ Pluses:Live data - same thing that our internal apps see, i.e. orders are created in real time, inventory is depleted right away
--- Minuses: Potential security risk, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
b) Build a separate Rails app on a web server, that will connect to a different DB from our internal app.
+++ Pluses: Less security exposure.
--- Minuses:Extra effort to sync web DB and internal DB (or using a web service like REST-API), extra code to handle inventory depletion and order # creation, duplication of code - i.e. I need to duplicate all the controllers, models, views, etc. that deal with orders.
c) Expose internal app to the web
+++ Pluses: all the problems from above eliminated. This is much "DRY"er method.
--- Minuses: A lot more security headaches. More complicated login systems - one for web & one for internal users using LDAP.
So any thoughts? Anyone had similar problem to solve? Please keep in mind that our company has limited resources - namely one developer that is dedicated to this. So this has to be one of those "right" and "smart" solutions, not "throw money/people/resources at this" solutions.
Thank you.
I would probably create separate controllers for the public site and use ActiveResource to pull data from you internal application. Take a look at
http://blog.rubybestpractices.com/posts/gregory/rails_modularity_1.html
http://api.rubyonrails.org/classes/ActiveResource/Base.html
Edit - fixed link and added api link
I would go for a. You should be able to create the controllers so that they are re-usable.
Internal users are as likely to duplicate data as external users.
It's likely that a public UI and an internal, for-the-staff, UI will need to be different. The data needs to be consistent so I would put quite a bit of effort into ensuring that there is exactly one, definitive database. So: one database two UIs?
Have a "service" layer that both UIs can use. If this was Java I would be pretty confident of getting the services done quickly. I wonder how easy it is in Ruby/Rails.
The best outcome would be that your existing Customer Java UI can be adapted to use the Rails service layer.
Assuming you trust your programmers to not accidentally expose things in the wrong place, the 'right' solution seems to me to have a single application, but two different sets of controllers and views, one for internal use, and one for public-facing. This will give you djna's idea of one database, two UIs.
As you say having two separate databases is going to involve a lot of duplication, as well as the problem of replication.
It doesn't make sense to me to have two totally separate apps using the same database; the ActiveRecord part of a Rails app is an abstraction of the database in Ruby code, therefore having two abstractions for a single database seems a bit wrong.
You can also then have common business rules in your models, to avoid code duplication across the two versions of the site.
If you don't completely trust your programmers, then Mike's ActiveResource approach is pretty good - it would make it a lot harder to expose things by accident (although ActiveResource is a lot less flexible and feature rich than ActiveRecord)
What version of Rails are you using? Since version 2.3 Rails Engines is included, this allows to share common code (models/views/controllers) in a Rails plugin.
See the Railscast for a short introduction.
I use it too. I have developed three applications for different clients, but with all the shared code in a plugin.
I shudder to ask, but my client might offer no other SQL (or SQL-like) solution. I know Access has some SQL hooks; are they enough for basic ActiveRecord?
Later:
I appreciate all the suggestions to use other databases, but trust me: I've tried convincing them. There is an "approved" list, and no SQL databases are on it. Getting something onto the list could take more than a year, and this project will be done in three weeks.
It's a long shot but there's an ODBC adapter for ActiveRecord that might work.
There seems to be something of an Access connection adapter here: http://svn.behindlogic.com/public/rails/activerecord/lib/active_record/connection_adapters/msaccess_adapter.rb
The database.yml file would look like this:
development:
adapter: msaccess
database: C:\path\to\access_file.mdb
I'll post more after I've tried it out with Rails 2.1
Another option that is more complicated but could work if you were forced to do it, is to write a layer of RESTful web services that will expose Access to rails. If you are careful in your design, those RESTful web services can be consumed directly by ActiveResoure which will give you a lot of the functionality of ActiveRecord.
There are some wierd things in Access that might cause issues and I don't know if ODBC takes care of it. If it does #John Topley is right, ODBC would be your only cance.
True in access = -1 not 1
Access treats dates differently than regular TSQL.
You might run into trouble creating relations.
If you go with access, will probably learn more about debuging AcriveRecord then you ever cared to ( which might not be a bad thing)
Maudite wrote:
True in access = -1 not 1
Not correct. True is defined as not being false. So, if you want to use True in a WHERE clause, use Not False instead. This will provide complete cross-platform compatibility with all SQL engines.
All that said, it's hardly an issue, since whatever driver you're using to connect to your back end will properly translate True in WHERE clauses to the appropriate value. The only exception might be in passthrough queries, but in that case, you should be writing the SQL outside Access and testing it against your back end and just pasting the working SQL into the SQL view of your passthrough query in Access.
Maudite wrote:
Access treats dates differently than regular TSQL.
Again, this is only going to be an issue if you don't go through the ODBC or OLEDB drivers, which will take care of translating Jet SQL into TSQL for you.
Maudite wrote:
You might run into trouble creating relations.
I'm not sure why you'd want an Access application to be altering the schema of your back end, so this seems to me like a non-issue.
You should really talk them into allowing SQLite. It is super-simple to setup, and operates like Access would (as a file sitting next to the app on the same server).
Firstly, you really want to be using sqlite.
In my experience Access itself is a pile of [redacted], but the Jet database engine it uses is actually pretty fast and can handle some pretty complex SQL queries. If you can find a rails adapter that actually works I'd say you'll be fine. Just don't open the DB with the access frontend while your rails app is running :-)
If your client is anal enough to only allow you to develop with an approved list of databases, they may be more concerned by the fact that Jet is deprectated and will get no more support from MS.
This might give you some ammunition in your quest to use a real database. Good luck