We are at the very start of a project which will populate a relational database with information from archives across the world. There will be three people working on the database and ultimately we want it to be openly available and searchable as an online research tool. Would Microsoft access on sharepoint be a good way of facilitating the collaborative research?
Microsoft access on sharepoint to create database ultimately destined 4 website?
(8 posts) (6 voices)-
Almost certainly not. Access is well-known for falling over dead given any significant load (either via size of database or number of simultaneous accesses), and it doesn't play nicely with non-Microsoft technology (such as what runs most of the Web).
What were you thinking Sharepoint/Access would do for you? Perhaps the DH hivemind can suggest a stabler, opener alternative.
Posted 7 years ago Permalink -
Arno Bosse
MemberI concur that Access is not a good choice. At Chicago my group former Humanities Computing group hosted a similar sounding project developed by the university library: Libraries and Archives in South Asia (LASA): https://coral.uchicago.edu:8443/display/lasa/Home
As you can see LASA is built around a wiki. It is a database, certainly, but a database whose content is exposed in a format that allows others to (optionally) contribute their own data, easily share results, search through the contents by keywords or browse it by facets, subscribe to an RSS feed of recent changes and so on. As you can see, by putting the content in a wiki you get a lot of very useful, user directed features 'for free'. The LASA wiki is built on Atlassian Confluence (http://www.atlassian.com/software/confluence/) which is a commercial wiki. I feel Confluence is by far the most feature rich and easiest to use wiki solution available today but it's not free (or even cheap..) and setting it up requires a fair amount of hardware resources.
My advice is still to build your resource as a wiki but to do this with a free and technically less demanding solution such as Dokuwiki (http://www.dokuwiki.org/dokuwiki). I personally don't recommend MediaWiki (even though it is far better known) since to me, at least, it is cryptic and unfriendly to use, difficult to extend and maintain and hasn't (to my knowledge) seen any significant updates in some time.
One potentially significant downside of a wiki-as-a-database approach to your task is that just as a wiki excels in helping you organize and share relatively unstructured data you will have a harder time of it than with a traditional database in exporting this data into a structured context afterwards. So, for example, while it should not be too difficult to move from eg. DokuWiki to another wiki, much more manual intervention will likely be required to move your content from DokuWiki to say another database. Without more background on your specific task and audience I can't properly say more to this but my gut instinct is that this won't actually matter.
Posted 7 years ago Permalink -
One specific question I have (after agreeing that Sharepoint doesn't sound like the ticket) is how the information would be coming in from the various archives? That is, are you looking at a lot of manual entry, or importing via OAI-PMH, or some other mechanism. My hunch is that that will be very big factor in what tool or platform will work best, perhaps even more important than the factors of displaying and sharing the information once it has been populated.
Posted 7 years ago Permalink -
georginalgreen@gmail.com
MemberReplying to @Patrick Murray-John's post:
Hello,
Thanks for the suggestions so far. I will look into them. Sharepoint was a suggestion as it is being used by another (pretty different) project at the uni. My concerns are the same as yours!
There would be a lot of manual entry -taken from a lot of handwritten sources, for example. I think we are committed to a conventional relational database, but I will look into the wiki idea. I was thinking of using MySql via a GUI (none of us are up to it without a GUI for inserts). I am uncertain how to access the database from a variety of locations. I also think we maybe should have data collection databases which we then merge somehow into a master database ultimately.
What do you think? Any tips appreciated.
Thank you!Posted 7 years ago Permalink -
Depending on the complexity of your database you might want to consider using Google Spreadsheets with Google Forms. You wouldn't have the possibility of establishing relationships between tables, but you could do field validation and constraints (through pull-down menus, etc.).
I suspect ultimately you'll need to build a custom web-based interface for the database anyway, and that could be query Spreadsheets through the API or you can migrate all the data into something like MySQL or SQLite. The real strength of Google Forms would be a free, collaborative platform for data entry.
Alternatively, you might want to try something like Zoho (I haven't tried it for databases).
Posted 7 years ago Permalink -
georginalgreen@gmail.com
MemberThanks everyone! The relational nature of the database is key to the research -we are trying to uncover complex, unforeseen patterns of membership, publication, etc. I am looking into MySql and ways to remotely access the MySql server or perhaps enter data offline to be synced once network access is available.
Thanks for your input it reassured me that I might be right to doubt the access / sharepoint solution. I'll look into all your suggestions and let you know how we get on.Posted 7 years ago Permalink -
If you're willing to spend between $79-$99 you'll find that Navicat for MySQL makes it trivial to import an Excel spreadsheet or CSV into a MySQL databse. As an added bonus, it's a great tool for working with the data as well: exporting, reporting, querying, etc. $79 for Mac and Linux, $99 for Windows. http://navicat.com
Posted 7 years ago Permalink
Reply
You must log in to post.
