It's sort of funny. We have moved from an early version of our db structure to a more "engineered" and flexible one. (don't worry, the db group is doing the design, not me). I think we had like about 6 tables when we went to them, and now we have 40+.
And that's why I love our tests. They allow us to make changes lower down and find out if we have broken things or not. (Unfortunately we don't have true unit tests... they connect all the way down without mock objects). That's one way that we've been able to stay agile. Another is to have the container manage persistence. We're more concerned about the business logic and don't have to do as much of the annoying part. ;-)
Now to just start using other methods that will enable us to stay even more agile and pick up mistakes early.
This is why an object persistence layer or a database abstraction can save you: you don't have to worry about everything below a defined API, and it can be worked on by another team. Government departments love to do this kind of IT turf seperation between developers and their databases.
ReplyDeleteAnd that's why I love CMP. All we have to do it map fields in our objects to fields in the db and hit a couple of keys to regenerate code.
ReplyDeleteCompared to doing object / db sync'ing with JDBC code, this is a joke in terms of difficulty.
What is CMP? Do you think it would be good for AudioMan?
ReplyDeleteCMP is "Container-Managed Persistence". It's used with EJB's (enterprise java beans). It's a way for you to easily tie (entity) objects state to a db. If you call a "set" method on an object, it changes the db so that it corresponds. If you call a "get", it checks to see if anyone else has changed the object since you used it. Of course there are different performance tweaks you can do so it doesn't do so many calls to the db. I'm still learning about it.
ReplyDeleteI don't think that you could use this for AudioMan since you'd have to run in a container... not something that you want in a desktop app that's supposed to be fairly small and lightweight.
http://java.sun.com/developer/technicalArticles/ebeans/EJB20CMP/
from 6 to 40+ tables? wow, that's quite a change. Were the old tables just that bad, with like 40 fields each, or do you have a bunch of tables that you aren't using yet, but that you know you will need for future functionality?
ReplyDeleteThe old tables were not great since we knew we were going to work with the db group. They were more of a "rapid prototype" type of tables. But the db group had tricks that I had never seen before.
ReplyDeleteFor projects, it's great to be able to work with people who really know their domain, and can help you out really early on.
All the tables that are in will be used. Why would we put tables in that we didn't have current functionality tied to? We'll modify the db when the time comes for that need...