I work for an architecture firm and we have a library filled with tons of magazines. I want to create a database where we can browse through our library by keyword, like let’s say we needed to look up I.M. Pei articles, we can search the database and it would tell us which magazine contained I.M. Pei articles. Anyone have any suggestions? Thanks.
Do you want a free one, a cheap one, or a good one?
A good and free database solution for many aplications is Firebird. It runs SQL queries correctly and takes much less setting up than MySQL does.
But, do you want to be able to search through the entire text of your magazines, or just to search on certain fields (such as author, title, release date, etc.)?
If you want to search on the entire magazines text then a specialised product, or even some web search engine based scheme may be best for you.
Any database can search through records. That is what they do. However, we need more info to recommend a solution.
How many users/screens?
Do you need network/internet access?
How many records?
Who will develop the software?
What is everything you want this to do?
Will it run on a server or just a desktop?
Firebird is sweet as Bippy the Beardless says. I use it and perl for all kinds of web based databases. linky
Work is willing to pay for one if that means it’s better, but if the free ones are just as good. We are all for it.
We don’t necessarily need to scan text - just keywords. Internet connection not really a necessity. Sorry I wasn’t too clear in OP on what we are looking for. Like let’s say a client wanted a “red door.” I would want to be able to type in the words “Red Door” and then it could give us a list of all the magazines that feature red doors, and then we’d be able to look them up and show the client. Is Firebird still good for that?
MS Access is pretty powerful desktop database system and it comes with some versions of MS Office. Companies often try to build systems much larger than you are proposing with it. It handles the database part easily and it includes the components to build the user interface, nice fancy reports, etc. The database itself can be housed on an a server or a regular PC. It handles smaller amounts of shared Access pretty well.
If you have it already, Access might be a good place to start. There are lots of consultant Access developers around for a fee or there are good books on it at any bookstore. The database you propose sounds simple so it could probably be done in house but the person that does it would be wise to ask about relational database theory and design either here or elsewhere. Database design is a complex topic but that is what I and several other people here do for a living. It doesn’t sound like this task is that hard though. However, there needs to be some initial thought put into it before building because poorly designed databases can really screw up the whole goal.
I also agree with MS Access…most offices have the Microsoft suite installed that contains MS Access so you might not need to pay for new software or licences, and it is indeed a powerful little program that should easily accomplish what you are trying to do. However, I think someone is going to have to spend a considerable amount of time going through all the magazines to input the name of the magazine, the issue date, the actual hard copy location and the key words to make them searchable. Then there is the problem of making sure the magazines are put back into the correct location and not left on the floor of a stall in the mens’ room. You might want to think this out very carefully before you begin and hire a librarian/data entry person to take of the taskl.
There is a way to actually scan all of the documents, and then have them available to be scanned for key phrases or words, but that is somewhat costly, very time-consuming and might be a long term solution rather than short term.
Another vote for MS Access. An excellent program once you get the hang of it, and you don’t really need to know any SQL to get the results you want.
Check with other firms, national organizations, etc. to see if there isn’t a architecture specific database available. The preference would be one to which you can subscribe and access over the internet and one that is updated from magazines such as you have. Creating such a database from scratch can be a horrendous task, especially for someone not familar with databases.
Bob
I agree with Urban1z.
What you describe is a fairly simple DB application. However, loading the data is going to be a huge job if you truly have “tons” of magazines. You do realize that you’ll have to enter all those keywords and the magazines they refer to, correct?
There are definitely places you can subscribe to that have done all the footwork for you already. Lexis Nexis is the big one. I’ve had luck with Highbeam.
FileMaker Pro cleans Access’s clock — it’s more user-friendly, it scales far better in a multi-user environment, and it’s cross-platform.
The same software used to design solutions is used to run them, and (assuming you have the privileges to make such changes) you can modify the structure while you and a hundred other folks are using it and looking up data and so forth.
Interfaces for data input double as interfaces for searching, and can double (triple?) as interfaces for printing (although some types of reports — those dealing with aggregate data and subtotals within categories — require a dedicated layout). Designing interfaces is famously easy in FileMaker.
While FileMaker used to have truly miserable native capabilities as far as putting your solution on the web and accessing it via browser, it’s now a solid publish-to-web. What you see in a web browser looks almost exactly like what you design for use within FileMaker.
The last couple of tiers of advances in FileMaker have made it somewhat more intimidating to dive into for the first time, but it’s still more user-friendly by quantum leaps than almost anything else out there.
MS Access is fine for some things, it may be good for you. If the data once you put it in the database doesn’t change often it can be fine. If you just want to catalog your magazines there shouldn’t be any problem with MS Access. If you want to be able to have many different users modify the database (say in keeping stock control on the magazine availability and allowing multiple users to modify stock counts) the MS Access will be a problem.
It is best to think of MS Access as a one user database, if only one person ever has the ability to modify the contents of the database, and everyone else can only look at the contents, then you should have no problems.
If you don’t have anyone with SQL (the Query Language) experience, and you do have people used to using office (especially if you have people who know VisualBasic) then MS Access would be a worthwhile database to use.
If you aren’t going to have the database available 24 hours a day, then MS Access is much easier to make daily backups from since it is only the case that you will copy the dbs file to your backup system, there will be no need to stop and restart any database server software. But MS Access does need to be backed up fairly often if you don’t have someone with good troubleshooting skills on your staff, when it goes wrong it can be painful to fix, and going back to the previous backup copy may well be the only viable solution.
My knowledge of Microsoft Access is from the MS Access 2000 version. With a complex database and two concurrent users it fails every month or so, I would absolutely not use MS Access for the setup we have (we’ll move it to Oracle ASAP, not a particularly easy task, but worth it in the long run).
If you have anyone with experience of SQL the Firebird is probably a better bet (or Oracle if you want to get the free version and have someone with DBA skills) Firebird takes far less DBA skills to use than Oracle or MySQL, and though Access makes some things easy to do, it makes making mistakes easy as well since it doesn’t encourage forward planning.
How dare you even mention the words “FileMaker Pro” in a discussion on databases?
I had to work with someone on a project a couple of years ago with an application written in FileMaker Pro. I was appalled to find that many or most of the things that database designers take for granted were either just plain missing, or so convoluted to use that it was ridiculous.
Want to have two tables with a foreign key relationship? Impossible in early versions, patched on as an afterthought in later versions, but with lots of hoops to jump through to make it work even halfway.
SQL statements to access or modify data? Forget it.
I could go on and on, but fortunately my memory has blotted out some of the more egregious sins of this “product”
If I never see another FileMaker application it will be too soon.
It’s almost as egregious as someone mentioning MySQL when tlaking about databases. Seriously, those are 2 directions you DON’T want to go.
For DBs less than 2GB in size, you can download a free copy of the SQL server Desktop Engine (MSDE), or for a couple grand you can pick up a “Standard” version of SQL Server. Both of these are robust database systems that are built to allow you to back up and restore data easily, accomodate multiple-user connectivity (ok, so MSDE allows 5 concurrent conenctions, I think), and remain fairly stable.
MS Access is limited, I think to 1GB, and it’s a real dog when you start loading it up that much anyhow. It’s a good tool for small databases, but tends to take less intelligent paths toward delivering results as you scale it up. I have no experience with Firebird, or another freeware DB, Postgre-SQL, but I have heard good things about them in terms of their integrity as DB systems.
I, meanwhile, am perpetually appalled at the things that database designers in other systems take for granted which are blessedly unnecessary in FileMaker.
Unclear from this what kind of relationship you are, or were, trying to establish, but I suspect you’re talking about the “tunneling” problem. (Products are related to Companies which in turn have Personnel, but from FileMaker 3 through FileMaker 6 you couldn’t reference Product-table data from a Personnel record without defining additional fields to “tunnel” the relationship).
FileMaker (even those older versions) are slick enough once you know how to go at it. You can do many-to-many-to-many relationships and so on.
You would generally have the pleasure of being able to forget it, but if for some reason you had to rely on klunky old Structured Query Language (“squirrel”), FileMaker has been able to speak it as a second language since ODBC compatibility started getting added in under FileMaker 4. But why (unless you were tying to an outside system) would you want to use squirrel when FileMaker’s native Find engine and its scripting architecture is so much nicer?
Other database systems are rife with klutzinesses and incapacities of their own. Limitations on how many different ways two tables can be related at the same time, for instance, or hell to pay if you rename certain elements (e.g., references to them don’t auto-update in report scripting or in other places — especially if all your “verbs” are written in a totally different sw environment such as Crystal Reports, ugh), or you can’t make modifications of any complexity while the system is live, or you can’t join tables except on the basis of a “primary key” in each table or some such thing, or you can’t relate between a number field in one table and a text field in another, or you can’t change the definition of a field-type from one type to another with any degree of ease, or you find that once you want to go beyond an array of pre-packaged “templates” or “modules”, the tools available to you as a designer are cumbersome and very generalized and more akin to writing raw application source code than using specialized development tools.
FileMaker turns off many db developers because it isn’t like the other systems they are used to. Mostly that has been a very good thing. Compared to 95% of the other types of productivity software that folks would use, most database software is awful stuff, intimidating and about as accessible as “here, just create what you need in this programming language and compile it”.
FileMaker is as easy to use as Excel or Word and yet it only bogs down and gets out of its league with huge datasets of tens of millions of records per table, or with a large and busy multi-user environment of over 200 simultaneous users doing constant searches and running reports.
FileMaker is totally not the tool to run the US Social Security Administration on, but for folks who want something between “a database for me personally to use on my own computer” and “a database for several dozen folks at my company to all use simultaneously to run our business on”, FileMaker is the sweet spot.
Don’t use Access. It’s too unreliable for what you need. You need something more robust, like SQL 2005 Express which is free.