 |
 |
In my experience, for a number of use cases, including possibly this one, a database is overkill. Often, flat files in a directory system indexed by something like Solr is plenty and you avoid the inevitable headaches of being a database administrator. Backup, for example, is a snap and easily automated. Roy > On Apr 15, 2016, at 11:37 AM, Scancella, John <[log in to unmask]> wrote: > > I would definitely pick postgres over mysql. It has all of the same features and more, plus it is easier to use (in my own opinion). > > But before I even pick a database I would consider these: > What are the speed requirements? > How do you plan on doing searching? > How much data? > Does it need to be redundant? > What about clustering? > Geographically diverse for faster local retrieval? > What languages or other technologies do you plan on interfacing with? > > and then, based on those answers more questions will arise. > Best of luck! > ________________________________________ > From: Code for Libraries [[log in to unmask]] On Behalf Of Ben Cail [[log in to unmask]] > Sent: Friday, April 15, 2016 2:23 PM > To: [log in to unmask] > Subject: Re: [CODE4LIB] Good Database Software for a Digital Project? > > I would suggest looking at postgresql <http://www.postgresql.org/>. It > may not be as widely used as mysql, but it is used a lot, and it's a > high-quality piece of database software. It's also free. > > -Ben > >> On 04/15/2016 02:18 PM, Matt Sherman wrote: >> Hi all, >> >> I am looking to pick the group brain as to what might be the most useful >> database software for a digital project I am collaborating on. We are >> working on converting an annotated bibliography to a searchable database. >> While I have the data in a few structured formats, we need to figure out >> now what to actually put it in so that it can be queried. My default line >> of thinking is to try a MySQL since it is free and used ubiquitously >> online, but I wanted to see if there were any other database or software >> systems that we should also consider before investing a lot of time in one >> approach. Any advice and suggestions would be appreciated. >> >> Matt Sherman