I've been searching/browsing forum and tutorials and don't deem to have found a clear answer to my question, so I apologise if this is old ground.
I have a client that has some fairly complex project management data needs... without going into detail, they have a fair number of projects (to be located in one table) in a number of communities (located in another), each of which can be at different stages and managed at each of these stages by different stuff (more tables with tables to link them). Currently our db schematic has some 30 related tables, though quite a few are simple 2 field tables that would be used to populate drop downs lists that would then provide the data for some of the other tables. At least two of the tables have latitude and longitude details to populate a googlemap, plus some freetext firlds that would populate pages on their front end site that gives details about the projects.
Clearly, I can write a set of pages using php and store them in a subdomain or directory to enable client to input and edit data (they might also be wanting to input some of this data by uploading csv files) and then use probably table_wizard and views to access the content, but I would like to create a complete Drupal solution for them if possible, so that if they ever had to take it to a new company, they wouldn't be starting entirely from scratch. Is the way I describe the best solution, or is there another route? Could I do this (including the cross referencing of tables, but obviously using nodes instead) using CKK to mimic the db structure as nodes for example,or would that be grossly inefficient?
Thanks in advance for any comments
Comments
I would start by looking at
I would start by looking at CCK. By using node based content you also get other features that are associated with nodes. You could use taxonomy and make a vocabulary for representing "lists of values". You could use views to list the content in various way and by using exposed filters let users filter the data as needed. If you use the date module and use it to add dates to your content types you could even use the calendar module to list when projects are due for example. And the list goes on ...
bridge vs migration
you can develop a module to make a bridge (kind of Object Relational Mapping) between your legacy DB and Drupal's
or you can build a fresh Drupal site which fit your needs and afterwards migrate all your data to the Drupal system
if most of your tables are 3rd Normal Form for dropdown lists, then those would be matched against Drupal's taxonomy
I would recommend you data migration, since bridge solutions won't take full advantage of Drupal's system and probably will have performance issues (besides complicated synchronization logic)
nevets, arhak, thank you both
nevets, arhak, thank you both warmly. Fortunately I am constructing the db from scratch then importing data currently in excel files (so easily transferable to csv), so will do it with CCK nodes (looking at the drupal db structure itself, it seems that my fears about it being inefficient were unfounded, particularly on the scale I'm likely to be working).
What would be the advantage of using taxonomy to create my dropdown lists as opposed to simply using another CKK node and using node reference field types?
CCK vs Taxonomy
If you're using several CCK fields I recommend you to stick with CCK
If you really want to know the difference search for it
http://www.google.com/search?q=site:drupal.org+"CCK+vs+Taxonomy"+OR+"Taxonomy+vs+CCK"&hl=en
Taxonomy is great for
Taxonomy is great for categorizing, for example lists of colors, transportation modes, etc. If the list simply serves to categorize I highly recommend using taxonomy. By using taxonomy you can access to a number of modules that work with taxonomy and easy ways to list all content categorized with X.
I would only use the node reference approach when the referenced item has it's own data (more than the just the name).
Again thanks... much to think
Again thanks to both of you... much to think about, but you've saved me much time in exploring deadends :-)