OK, I’ve done some of this kind of thing before.
I would, in the case, recommend putting the data into SQL form. That way searching, displaying, etc. could all be done much more efficiently. Where the difficulty would come in is managing it. It sounds like there’s relationships between the data in a variety of ways and it sounds like you need an interface to then allow you to manage that data.
How you’d approach that within EE would have a lot to do with how those relationships work AND/OR how much traffic this data will create. Is this a niche area where you probably won’t ever have large numbers of visitors hitting the site and the data being pulled or would it be something you’d need a high level of performance? It also kind of depends on what you mean by large database. As that doesn’t really give me an idea of number of entries.
It may be that the EE weblogs/channels (as they are now called) will be all the functionality you need. You can already create relationships between section channel entries within EE’s core functionality. And of course you can have a field for each column of information. Or using the Matrix extension by Pixel&Tonic;you could have the columns in slightly slicker setup.
But there’s drawbacks to using channels with large data sets. They assume some things about how searching/sorting will work. And they are pretty heavy on the SQL server on the display end especially if you start sorting on any custom fields. More troublesome when you want to do some pretty bespoke stuff on the user end the data is all stored on a separate table from other entry stuff like date and title.
The way to get around that is to build your own interface to a custom table using EE’s module setup. I’ve done this in a few cases. But the onus is then on you and your developers. You need to create your own CP interface to that data and your own tags to then pull the data out. The plus side is that you can tailor the SQL tables to exactly what you need and want both in terms of performance and in terms of the types of data you are storing.
The investment in time and money will be higher with this second option and obviously you’d need someone who knows how to do all of that. I could see both approaches working but the right choice is dependent on your needs and means.
Jamie