3

Currently I'm trying to select the best DB paradigm to implement a web site with full-text search and faceted search capabilities. I have an important functional requirement:

The database paradigm should support strong conceptual schema modifications during every part of software lifetime.

As a example, our business can pose an extra data item over a registry that should be taken into account in any search. If we use a relational paradigm, this modification requires to alter the database schema (by adding or deleting rows and modifying foreign keys etc.). Obviously, this can lead to maintainability unwanted issues.

  1. Should we use a document based DB? (i.e. an XML database)
  2. This problem can be treated as a purely relational conceptual schema design challenge? (i.e. we could design the relational DB having in mind the stated constraint)
  3. Do you think that this problem should be treated using a specific paradigm?
Improve this question
3
  • Please state you question in terms of the specific problem you are facing. Asked in these terms this is just a "list of" question.
    – ChrisF ♦
    Aug 8, 2011 at 17:33
  • what kind of app you are doing -- if you tell us that, it will narrow down the answer to address your specific context
    – treecoder
    Aug 8, 2011 at 17:42
  • I've narrowed the question. Hope this works!
    – JPCF
    Aug 8, 2011 at 17:52

2 Answers 2

Reset to default
5

I might suggest an alternate route: use a indexing/search library like Lucene or Lucene.net. They've already implemented a lot of the intricacies of indexing, search syntax, and optimization.

(Not sure if those are appropriate, you didn't mention a specific environment or language)

If you're set on implementing your own database, there's going to be design considerations that you haven't mentioned to take into account. For example, can users search just by words and phrases that would map to a SQL partial text query (select * from documents where content like '%keyword%') or would you want to be able to specify keywords, search by field, search by date, etc?

Improve this answer
3
  • 1
    Hmm... the problem is not exactly indexing. We concluded that Lucene was our indexing solution (try creating a new DB engine from scratch!!! argh! ). Specifically, we want to tackle increasing categories that can appear on our data. i.e. initially you have a person with address and name, you db has been designed to ask for this data; suddenly, you need to modify this simple schema to add cat's name...
    – JPCF
    Aug 8, 2011 at 18:04
  • Would this new field need to be added to existing documents or just new ones? I don't think Lucene has a set schema, really. Just documents with fields, so it's a bit like NoSQL.
    – David Hogue
    Aug 8, 2011 at 18:24
  • the new field is going to be added to existing documents...
    – JPCF
    Aug 8, 2011 at 20:10
3

Another choice is an Entity-Attribute-Value model. If you do this in most modern rdbms, you can get full-text search as well.

There isn't enough information to know whether you application is a fit for this. There can be performance concerns and having to transpose the values into separate columns amy present coding challenges to do this dynamically.

There are plenty of posts on the pros and cons for NoSQL type databases.

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.