Slashdot Mirror
Specialized, Open Source Databases?
PyTHON71 asks: "I've been asked the head of the Wichita State University Anthropology department to help fix his growing biological anthropology collection database. It's currently in Access (insert boo's and hisses), but he is willing to have it developed in a reliable open source format. Now, there are a lot of university departments out there that need to have specialized work done on a small budget. They can't rely on just any developer, because the developer has to know biological anthropology (in this case) as well as MySQL, etc. And since it's not in the Hacker Code to duplicate work that's already been done, I was wondering what specialized database projects are out there & available for general use (not the data, just the structure)."
Why does the developer have to know biological anthropology? Can't the developer just work with the scientists to understand the data formats, and create the database for them, and then teach them how to use it?
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
* Let me create front-end forms populated and controlled by code and query
* Support relational tables, indexes, complex JOIN queries, aggregate functions, etc.
* Design complex reports with page/section formatting and behind-the-scenes code controls
* Can access ODBC data sources
If you can show me the way, I'll take the first step! I'd love to cut some of the distribution costs here!
GTRacer
- Needs help with gcc + PS2...
Defending IP by destroying access to it? That makes sense, RIAA/MPAA. Go to the corner until you can play nice!
http://bioinformatics.org/
End of thread
Why dont you explain what you mean by 'database' first. A database can mean different things. I am not sure if you want a complete database application, front end and all, or if you just want a database design- A UML model or E-R diagram, from which SQL DDL can be created. (or perhaps by open source you meant SQL code to Create a database). Your requirements are kind of blurry to me. Doing something like this should not really be all that difficult though. If you have a developer look at the kinds of data you are trying to store, and the relationships between those data (in depth knowledge is not required of what the data actually means, though I guess it helps) a developer should be able to come up with a Data model and front end relatively easy.
A database is a database. There is no "specialized" database for any purpose, with the possible exception of design for platform (IE, DB/2 for AS400) - you build the structures in the DB program and go. It's what makes apps and engines like MySQL really cool.
If you want a DB that is geared for bio-anthropology, fire up MySQL or PostGreSQL or insert your favorite engine here, build the structure for the DB you need to run, put a pretty face on it for the users, and kick back as it does the rest.
This sig no verb.
The requirements seem kind of vague, but if you don't want to go all the way, you could always just export the data to PostgreSQL or mySQL, and use the the existing access interface for a frontend, connecting over ODBC to the Open Source alternative - at least until you've transitioned it to something else.
Here's what I understand:
.csv from word, and import to your chosen database... interfacing should be similar, it depends on how you're accessing it (if web based, and you have admin privs on the host machine, you just change the database type in the control panel, google:asp+mysql )...
you already have everything up and running on an access database
you want to use a different database platform
doesn't sound like you need to worry about designing anything, its already there.... especially if you want to go from access to MySQL (or any other of the same family), just build the database structure to match the old one, export to
so unless I've over simplified something, sounds like this is a classic mountain != molehill problem
It supports almost all sql92, is blazingly fast, it has an ODBC interface and native api's for c and c++, is has a python db api 2.0 compliant interface. It has a really cool and versatile command line tool. It is imbedded though, so if you want to you it as a server you will want to write the implementation. I don't think that it would be too hard though, depending on what you wanted to do with it. I have just started a payables application withit and it looks like it will work out quite well.
Oh, and it is public domain.
I found my inner child, then I got caught abusing it...
A generalized forum such as "Ask Slashdot" probably isn't the best place to ask this type of questions. The problem is that the domain is too specific. What you probably want to do is talk with other biological anthropologists and see if anyone has a schema that you can adapt to your needs.
That being said, one thing that you might want to do is search Google for XML schemas. I do a lot of (relational) database design and I've noticed that there are XML schemas for just about everything. (Although I generally dislike XML, a real benefit is that it promotes the idea of sharing information and schemas. In the relational database world, we tend to horde our schemas because they are viewed as competitive advantages.) Even though I typically don't use XML in my own projects, I've found that reviewing relevant XML schemas can sometimes help in the database design process. (If nothing else, it can help point out what not to do!)
You will also have to ask who will continue to support the app/db combination in the future. With any dedicated database server, who will keep it patched and secure, and backed up in the future? I see the following options:
1. Stay with Access:
Security is based on file sharing, and up to the Network Administrators. However, the problems with Access, you are probably well aware of; a biggie is that the db can lock and require reboot of the server (which can really piss off your Network Administrator if they have to take down a major file server for one application). Anthro may have already decided that Access is a bad thing(tm), but it may be good to gather a few quick arguments against it as justification against any MS flag wavers.
2. Migrate to MySQL (or other free DB) back-end with Access front-end:
You will have to figure out who maintains the server setup. Access does not like to migrate to non MS databases, and you may have to totally redo the db structure and Access front-end.
3. Migrate to MySQL (or other free DB) and rewrite front-end:
Again, you will need to figure out server maintenance, as well as finding an open-source front end. I'd be positively giddy to find/learn about an Access/Oracle Forms-like open-source tool.
4. Migrate to Microsoft SQL server with Access:
There may be other SQL servers on campus or with your IT department that you could rent space on. They would perform all maintenance with the server and the Anthropology department would just need to maintain the front-end. I would especially recommend server consolidation if you consider a Microsoft SQL server back end. Keeping up with patches, security, and other considerations with this server greatly outweigh the all-eggs-in-one-basket and local control factors.
5a. Does you university have an Oracle site license?:
You may be able to rent space on an IT Oracle server. However, I do not yet have experience migrating an Access DB to Oracle.
5b. If your university has an Oracle site license, does that include Oracle Forms Developer?:
Look at Oracle Forms developer as a replacement for Access (try version 6 before the latest 9 version, it's a bit more mature/easier to deploy until 9's bugs get worked out). It does have a steeper learning curve than Access, though.
Of these choices, 2 is my pick for ease, 3 is my pick for open-source, and 5a/5b would be my pick for an industrial strength solution.
"Inexpensive"? Haven't we graduated to "free" yet? Why waste time looking for an "inexpensive" database when one could get a free one?
A generalized forum such as "Ask Slashdot" probably isn't the best place to ask this type of questions.
You'd think that...but amid all the noise and chatter of people pimping their own pet databases, they got your actually useful comment.
May we never see th
Matt Dillon (of FreeBSD fame, not the actor
cpeterso
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
As I understand it, the *NIX equivalent of Access is Berkely DB. Small, lightweight, stores all its information in a single file. They've got 4 different versions depending on your needs and support pretty much any OS.
"Don't blame me, I voted for Kodos!"
Something that's important to look at is who will support this application down the road. Funding at universities can be dicey, and this thing may have to be supported by inhouse flunkies. What can they reasonably support? This doesn't necessarily mean that it needs to be in access because the inhouse flunkies only know access. If you could write a C++ front end that was stable and reliable, with an easy-to-maintain connection to a backend that they can support, that might be a better solution. That said, some great recommendations have already been made. SQL-Server on the backend, if there's already someone maintaining one, would be ideal. I actually don't recommend putting an Access front end on things though, because a user with a little bit of knowledge can do a lot of damage.
Easy Online Role Playing Campaign Management
OpenOffice + MySQL
7 .b arr.html
see the Trail of Tears article - write up what you learn so the trail getts better
http://www.linuxworld.com/site-stories/2003/020