2

I'm building a web app that requires me to store metadata about files, approximately 15-20 "characteristics" for each file, including some shared ones (i.e. user1 & user2 should have access).

Would you recommend using a relational database for this? or is one of the newer more scalable noSQL databases a better option?

It should be something that scales quickly - and allows us to read and write fast.

Not sure how that would work with a relational DB in terms of performance (say im trying to find all the files that are owned by user1 and shared to user2 that have a certain property - I would essentially have to join 3-4 tables together... which is probably bad for performance?!)

Thanks for your feedback!

user1198133
  • 169
  • 1
  • 1
  • 7

4 Answers4

2

I don't think JOINing 3 or 4 tables would cause bad performance. If you are considering open-source relational solutions, I would suggest PostgreSQL, which is the richest SQL implementation currently. But MySQL will work, too, or even SQLite. They all have decent performance.

On the other hand, if the metadata that you need to store will expand in the future, a schema-based database will be a hassle. In that case I would instead suggest a schema-less (aka document-based, NoSQL, etc) database, like the open-source MongoDB. With indexes, it will also have excellent query performance. CouchDB is a richer implementation, but they don't pay as much attention to speed.

P Varga
  • 19,174
  • 12
  • 70
  • 108
  • Thanks!Do you mean expand columniwise (i.e. number of characterisitcs we store) or do you mean expand in terms of number of entries? - The latter is certainly true - the former - unlikely.. - what i dont like is that its relatively impossible to do a join in nosql type dbs... as far as my understanding goes.. – user1198133 Feb 12 '12 at 06:32
  • I mean the former, data expanding columnwise. If you go the relational way, then going the REAL relational way would provide some of the same advantages as NoSQL. I mean instead of a table (filename, someattrib, someotherattrib), I suggest multiple tables (fileid, filename) then (fileid, someattrib) and (fileid, someotherattrib). This is more flexible (a file can have more than one attribute of each type, and easier to extend later (`CREATE TABLE` instead of `ALTER TABLE ADD COLUMN`) – P Varga Feb 12 '12 at 20:05
1

I think a relational database is a good fit for this. NoSQL databases typically don't allow easy and flexible querying. That is a strength of good old SQL databases.

usr
  • 168,620
  • 35
  • 240
  • 369
1

Storing documents and some info for them isn't the strength of SQL databases.
I wouldn't choose MySQL, because of its license (or rather that of its data providers), and because you cannot say what Oracle is going to do with it in the future.

You are looking for a NoSQL database that is optimized for storing documents, that is extremely fast, and easy to setup (and use).
One that was written in C++ and not Java, and that non-the-less has bindings for .NET and Java, I assume.

I would say MongoDB would be the ideal choice.

Stefan Steiger
  • 78,642
  • 66
  • 377
  • 442
0

Why not use a vcs such us svn or hg where you can assign attributes to files? This all depends upon what you want to do with the information.

Chriseyre2000
  • 2,053
  • 1
  • 15
  • 28