Subject: Re: Database design / OO programming - msg#00058

Previous Message by Date: click to view message preview

Re: How much documentation is sufficient?

I guess a key thing that has been missed in my organization is cross team communication, for which has been pointed out by you all. The scenario is like this, we have 2 teams, one is the solution team doing the system integration work with external client by using the product that was developed by the team I belongs to, i.e. the product development team. We have many incidents that, the solutions team has always been having difficulty to finish their project, they don't know how to use our product, what can or cannot be done and what are the behavior that should be expected. And that's why they raised the request for our design documents, admin documents or operational guide. I believe with the frequent discussion that was hold among the two teams should minimize the lack of understanding from both of us. But there should still be a phase for documentation, I mean, we just cannot gurantee the developer will keep staying in the company. Thus, what kind of documents will you guys be willing to prepare, such as the user requirement which might not be easily be understood from the code itself. Besides, are there document format that you will follow? Appreciated for all of your reply! Ronnie Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Next Message by Date: click to view message preview

Pragmatists in Springfield, MO?

Greetings group, If there is anyone on this list from the Springfield, Missouri, area could you email me off line? Thanks, Joe bothari-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Previous Message by Thread: click to view message preview

Re: Re: Database design / OO programming

From: "Wouter de Kort" <wouter_dk-PkbjNfxxIARBDgjK7y7TUQ@xxxxxxxxxxxxxxxx> > But how would you imagine the Denormalized database? If I have a > client with 2 addresses and one with 12 addresses I would have a > problem in designing my database( how much columns? ). Or would you > save this in your Transactional database just like you would do it > in your normalized one? ( With 2 tables, Client, Address ) but > without all the checks so data can be added quit fast and can be > corrected before finalising it? > That's precisely the reason for putting Addresses in their own table: You don't know how many there will be. Your relational tables might look something like this: CLIENT Client_PK NUMBER Name_First VARCHAR(30) : ADDRESS Address_PK NUMBER Client_FK NUMBER Street VARCHAR(40) State CHAR(2) Zip VARCHAR(9) The Entity-Relationship Model for these would look like: CLIENT -|---< ADDRESS In other words, a one-to-many relationship: One CLIENT can have many ADDRESSes but each ADDRESS record can only point to one CLIENT. If you have multiple CLIENTs at the same address, such a database would require duplicate ADDRESS records for each of those CLIENTs. If this were a frequent situation for your business, you could design it with no Client_PK column in ADDRESS and, instead, maintain a CLIENT_ADDRESS "associative" table like: CLIENT_ADDRESS Client_PK NUMBER Address_PK NUMBER This would allow any address to be associated with as many clients as required. Let me take this opportunity to dispell a myth: JOINS ARE NOT SLOW! At least not on a reasonably well designed relational database. And in particular when you let the database engine do the joins by creating views. What often happens in application program implemented joins however, is that the interfacing code (ADO, JDBC, etc.) winds up pulling one or more of the tables into the program space in its entirety when it isn't necessary, simply because it doesn't know any better. The program can never know as much about the data distribution in the database as the database engine. To get maximum benefit of that knowledge that lets it utilize data already in its memory buffers, ignore data (even whole tables sometimes) that are not needed and other tricks, you need to use views created in the database environment (i.e. SQL Server, Oracle, etc.) Joins are not slow. Programs pretending to do joins but really stepping through ever record in the tables in order to find the matching ones ARE slooooow. > > Note that the Transactional tables contain what might be called > unvalidated "candidate" data. We want this exact record of what was > entered but it might not be correct and thus might get rejected when > we try to move it into the Relational tables. This is where things > get tricky and the desire to eliminate the Transactional tables pops > up. Don't Do It! You'll pay with your professional life down the > road. It would be like riding a motorcycle without a helmet. You > fall. You're dead. Period. The solution is to test for and > anticipate all the failure modes you can and provide clear feedback > to correct them in the data-entry phase. Then you code generic > error trapping in the triggers or equivalent methods that produces > all the documentation you need to correct the problem on the back > end. > > OK. I will look into it. It sound's like a good approach but a lot > of work. Couldn't you handle all the error checking to the class > Object before it's stored? > You want to handle everything you possibly can anticipate in your class object, but recognize that you will never catch everything. Thinking that you can is just arrogance (this from Mr. Arrogance Extraordinaire himself -- me) that will come back to bite you in the a-- later. We try mightily to account for everything and part of that is implementing the "layered" approach of not relying solely on the application program, but also using foriegn keys, check constraints, etc. in the database. Remember that all changes may not be made through your application program. Someday there will be a quick fix needed and a program will be written to change all records in a table in some way. If that change violates data integrity in some cases, you'll never know it if there is no enforcement in the database. The result could be delinquency notices being sent to the wrong clients, shipments goin g to the wrong address or any of countless other embarassments. > > There will always be fields no one thought of that need to be > added and if you can't accommodate them quickly, the users will put > the data in fields intended for other purposes, thus destroying the > integrity (correctness) of your database. So I also highly > recommend providing one or more generic tables and corresponding > user interface of a form something like: > > > > MISC_DATA > > Misc_Data_PK NUMBER > > Data_Name VARCHAR(30) > > Data_Value VARCHAR(255) > > > > They're not pretty, but this way you can collect the data and move > it into your relational database tables properly when you do get the > new fields added where they belong. > > > > So with this code you could create new fields 'on the fly'? But say > someone suddenly wants to save a new field in the Client class. You > could register that field with one of the MISC_DATA fields in > runtime but how would you add the 'real editfield' in the GUI? If > there is an option to store new fields in the database the user > should have the ability to edit those fields. > The Data_Name column contains the code name of the Data_Value. This name doesn't have to be exactly the name you will use for the column you finally create. In fact, it should generally be the label text so the users will know what to put in. Because the text (code) in Data_Name must be identical for all records containing the same kind of data, the users should not have access to it. It should come from a table of code phrases for that purpose. To enter this data you might have a button on the data entry window that would pop up a window with a couple of columns: one containing the predefined Data_Names and next to it the fields of the Data_Values. Here's a mockup for a window containing miscellaneous data attached to the STORAGE UNIT table. As I used to be in disaster management, I've used as an example something you might need quickly but probably would not have built in from the start. First is the table layout: MISC_STORAGE_UNIT MSU_PK NUMBER Storage_Unit_FK NUMBER Data_Item VARCHAR(30) Data_Value VARCHAR(255) MISCELLANEOUS STORAGE UNIT DATA Data Item | Data Value ------------------------------|-------------------- Temp Temperature Setting | 0 Number of Bodies | 39 Identified (Y/N) | N Agency Authorized to Enter | Coroner Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

Next Message by Thread: click to view message preview

Re: Re: Database design / OO programming

From: "Wouter de Kort" <wouter_dk-PkbjNfxxIARBDgjK7y7TUQ@xxxxxxxxxxxxxxxx> > > <robertcwatson@xxxx> wrote: > > <snip> > > > > > ORDER OF DATA INSERTS and UPDATES: > > 1) Application Program to > > 2) Denormalized Transactional Database to > > 3) Normalized Relational Database to > > 4) Optional Denormalized Reporting Database (i.e. Data Warehouse) > > > > I've still got a question about this.. > > If I have a Client/Server setup I think the transactional database > should be on the Client. A separate thread copies the data to the > Server where triggers/stored procedures/constraints check the data > and if something is wrong trow an exception which is send to the > Client. > If the transactional database tables are on the same database server engine with the normalized data, then the database engine can be used to move the data into the relational tables far faster and more efficiently. Since you can't use triggers for this in your particular environment, some, but not all, of that speed increase is lost. There remains the benefit of faster execution by keeping the data on the DB server and not having to move it across the network two more times (into and out of the client program). Ideally, you want the changes to the relational tables to occur within fractions of a second after the transaction table entries. Having to cross the network not only takes several times longer than could be done internally but also introduces unpredictable and difficult to compensate for data integrity errors caused by dropped connections which happen frequently in every net work. These are largely unnoticed by most users since email, browsers and even typical client-server applications have retry code in them. You'd have to build that into the client code for moving the transaction data too, but the amount of data flow activity is going to be much greater so the number of retries will be much greater. Than can often create bottlenecks that suck up all the CPU and grind things to a halt. There's also the problem that the transaction tables are as important to record keeping as the relational tables. If they are on the individual client machines, then how would you get access to that data? Go to each and every client computer? Pretty inefficient. What about the security aspects of storing that data on the client machines. What about backup and having big enough disks on the client for several years worth of data? > But what if a User types in some data, stores this in the > transactional database and starts working on something else before > the data is send to the server and processed? It could happen that a > User suddenly gets an error about something typed in a while ago. > > How do you make sure this can't happen? > The application should only do popups for errors detected in the current record. Other errors should be reported through a separate interface such as an error handling window. Such a window might have one error per line that can be clicked on to bring up the record for updating. Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/pragprog/ <*> To unsubscribe from this group, send an email to: pragprog-unsubscribe-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/