Comments on: Large Aquarium Database ? http://aquarium-fishtalk.com/large-aquarium-database/ Aquarium sharing blog and videos Fri, 25 May 2012 06:28:58 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: oracle128au http://aquarium-fishtalk.com/large-aquarium-database/comment-page-1/#comment-40410 oracle128au Sat, 13 Mar 2010 02:59:17 +0000 http://aquarium-fishtalk.com/large-aquarium-database/#comment-40410 I'm sorry, but are you both a DBA AND a Marine Biologist? If not, why are you taking on both roles? Here's how it works in the real world: you have a client/customer, that's the aquarium, who have certain needs for this database. Then you have the consultant, that's you, who interprets these requirements and produces a functional specification. Then you have the DBA, which in this case is also you, who goes and designs and creates the database based on the requirements and functional spec. But here, you've gone right ahead and jumped into trying to design the database, without knowing what the requirements are. Bad news. You can design your database as well as you want, and do as much research into aquariums as you can, but end of the day, I guarantee 100% that what you come up with isn't going to fulfil all of the client's needs. And, the needs of one aquarium aren't necessarily going to match the needs of your aquarium. All you have right now is a tiny list of fields and possible DB entities that you THINK might be needed for an aquarium database. Here's a quick example: you think you need the quantity and type of fish. That's it. Really? You don't have to store details on the species, sub-species, common name, scientific name, family, list of fish that go well with it, list of fish that should be together, whether they're saltwater or freshwater? These are just a couple of fields/relationships I can come up with off the top of my head. We could do this all day, but when it comes down to it, you really have no idea what level of detail is required for this thing, do you? Does the client have an existing database you have to hook into, or migrate across from, that might compromise your design? Is there a HR or payroll database you might need/want to use for staff lists? As I said, first step is to find out what exactly the requirements are. Double check them with the client. Build a prototype, and look for any potential problems. Make some suggestions. Go back to the client and check again, I guarantee there will be more and/or different requirements. From there, it should be a piece of cake to figure out the ERD. With the ERD, build your DB. DON'T build proper forms or reports yet - whip up some quick examples (use the wizards if you want to), show them to the clients, they will come up with more fields that they need. Some of these requirements may even be new entities, but 99% of the time it won't change your existing ERD, only add to it, so it should be an easy job from here. Once you've got all that, THEN you can start working on reports, form design, and other end-user stuff. Here's some more tips: -Make sure to leave your forms flexible - leave room for more fields, and if it makes database design sense to use multiple forms for entering something, do it, even if it doesn't make sense as GUI-wise. This way you won't clutter your forms when you inevitably have to add more fields and finding they won't fit. -Same thing with reports - you'd be surprised how few fields you can include on even a landscape-oriented report, when you have to cater for each column to its maximum possible width. Flexible and minimal is good - find out what info they want on a report, and don't include anything they don't ask for. Adding a form front-end to reports allows users to filter or customize them as needed - they will want that. -Just because the client doesn't ask for something the first 10 times you ask them, doesn't mean they don't want it. Preparing for it with a good, flexible design means less work for you. -I'm assuming you're doing this work as a contractor. So when done, leave them your details. I bet you you will be getting repeat business as they find stuff that doesn't work are they want more functionality. BUT, DON'T get caught into a trap of having to provide free support for them for all eternity. You might find they are constantly coming at you with small bugs/changes, and you'll find it's not even worth charging them for it. The first couple times, that's ok. After that, make them bundle up their bug reports/changes, and deal with them all at once as part of separate, paid contract work I’m sorry, but are you both a DBA AND a Marine Biologist? If not, why are you taking on both roles?
Here’s how it works in the real world: you have a client/customer, that’s the aquarium, who have certain needs for this database. Then you have the consultant, that’s you, who interprets these requirements and produces a functional specification. Then you have the DBA, which in this case is also you, who goes and designs and creates the database based on the requirements and functional spec.

But here, you’ve gone right ahead and jumped into trying to design the database, without knowing what the requirements are. Bad news. You can design your database as well as you want, and do as much research into aquariums as you can, but end of the day, I guarantee 100% that what you come up with isn’t going to fulfil all of the client’s needs. And, the needs of one aquarium aren’t necessarily going to match the needs of your aquarium.

All you have right now is a tiny list of fields and possible DB entities that you THINK might be needed for an aquarium database. Here’s a quick example: you think you need the quantity and type of fish. That’s it. Really? You don’t have to store details on the species, sub-species, common name, scientific name, family, list of fish that go well with it, list of fish that should be together, whether they’re saltwater or freshwater? These are just a couple of fields/relationships I can come up with off the top of my head.

We could do this all day, but when it comes down to it, you really have no idea what level of detail is required for this thing, do you? Does the client have an existing database you have to hook into, or migrate across from, that might compromise your design? Is there a HR or payroll database you might need/want to use for staff lists?

As I said, first step is to find out what exactly the requirements are. Double check them with the client. Build a prototype, and look for any potential problems. Make some suggestions. Go back to the client and check again, I guarantee there will be more and/or different requirements. From there, it should be a piece of cake to figure out the ERD. With the ERD, build your DB. DON’T build proper forms or reports yet – whip up some quick examples (use the wizards if you want to), show them to the clients, they will come up with more fields that they need. Some of these requirements may even be new entities, but 99% of the time it won’t change your existing ERD, only add to it, so it should be an easy job from here.

Once you’ve got all that, THEN you can start working on reports, form design, and other end-user stuff. Here’s some more tips:
-Make sure to leave your forms flexible – leave room for more fields, and if it makes database design sense to use multiple forms for entering something, do it, even if it doesn’t make sense as GUI-wise. This way you won’t clutter your forms when you inevitably have to add more fields and finding they won’t fit.
-Same thing with reports – you’d be surprised how few fields you can include on even a landscape-oriented report, when you have to cater for each column to its maximum possible width. Flexible and minimal is good – find out what info they want on a report, and don’t include anything they don’t ask for. Adding a form front-end to reports allows users to filter or customize them as needed – they will want that.
-Just because the client doesn’t ask for something the first 10 times you ask them, doesn’t mean they don’t want it. Preparing for it with a good, flexible design means less work for you.
-I’m assuming you’re doing this work as a contractor. So when done, leave them your details. I bet you you will be getting repeat business as they find stuff that doesn’t work are they want more functionality. BUT, DON’T get caught into a trap of having to provide free support for them for all eternity. You might find they are constantly coming at you with small bugs/changes, and you’ll find it’s not even worth charging them for it. The first couple times, that’s ok. After that, make them bundle up their bug reports/changes, and deal with them all at once as part of separate, paid contract work

]]>