all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||
|
|
|
Orange
|
|
|
Sorry, no photos available for this element of time.
|
|
|
|
Notes:
|
|
On a GoToMeeting session with Alan. We were brainstorming on the world building database project. We talked about the available option on the solar system table. That might be where we go in and prep a server and setup a number of shell databases (blank databases) and also ColdFusion datasources to go along with the shell databases. We then check to see what ones are available and virtually claim them as needed. That way we could prep and virtually stock the shelves on the servers so that things would be ready to go. Alan is going to look into cross database options. That could be good and it could be bad. We are going to check into it. Maybe even make a pros and cons list of options. During our session, Alan was playing around and doing some cross joins with multiple MySQL tables from different databases. Pros Traditional (new datasource per): - Meant to be done this way. - Just change the datasource and all existing queries would remain the same. - Easier for future developers. - We do all of the switching and lifting behind the scenes. - Faster processing and development time. - Less errors likely - if done in a traditional way. - We could use a developer to set things up and then make tools that a middle ware developer could use at a point and click level. - We could see the size of their data and the total footprint better. - If we need to move and/or load balance something, we could grab the whole database and just move it. We would have to worry about other dependent pieces. Self contained. Cons Traditional (new datasource per): - Lots of duplicate tables and records (look-up tables, or standard tables) - Updates on the existing tables would be harder. - There might be errors and places where things get out of sync. - It does take a developer to set things up (originally). - You could max out the number of registered datasources. We saw a forum entry that a person was having problems when they got up into the 800 (ish) level for number of single databases and datasources per ColdFusion box (CF administrator stuff). ------------------------------------------------------ Pros Single Datasource (shared datasource but separate databases): - Nice for a hosting type environment. - We wouldn't have to setup any new datasources. Cons Single Datasource (shared datasource but separate databases): - Hard to understand and/or explain. - It feels like a small hole and/or backdoor approach. Possible security problem. - This would give access to all databases from one single master datasource. - If someone figures out what master datasource is... they virtually have a key to the entire house. - We would have to define and code each query to flip flop and use clustrer controller tables and database specific tables. Lots of aliases and virtual pointers. - This could slow down the development time. - It would require more database knowledge from our developers. Mixing databases within a single query. - We would need to totally revisit permission on the user levels, the database levels, etc. This may take some research and implementation. - What about bottle necks, threading issues, locking issues, etc. This comes down to performance. One of our next steps will be to look at the database and see what will be cluster level vs. solar system level. |