<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-06-26 13:30 GMT+02:00 Graeme Geldenhuys <span dir="ltr"><<a href="mailto:mailinglists@geldenhuys.co.uk" target="_blank">mailinglists@geldenhuys.co.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br></blockquote><div><br></div><div>Hello,</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Last night I was working on a relatively new project. This got me<br>
thinking... How do others tackle such a task?<br>
<br>
So here is my question:<br>
<br>
  When faced with a new database related project, where do you start? Do<br>
you first design the database schema, then build the BOM (Business<br>
Objects) accordingly? Or, do you first design the BOM, then design the<br>
database schema to fit.<br>
<br>
Personally, most of my project were started by first creating the<br>
database schema. Don't ask me why, that is just what I did. Maybe it was<br>
because many of the tools I use, can write much of the boiler plate code<br>
for me, and they do that by querying a database structure. But I've been<br>
thinking that with my next project, I'm going to start with the BOM<br>
first, and see how it goes. I'm assuming the end result should be the<br>
same, no matter which part I tackled first.<br>
<br>
What's your thoughts?<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div><br>IMO, it depends on the complexity of the project. In simple projects (a few tables), usually the BOM maps exactly to the database, so I do both at the same time. But in complex projects, BOM can be significantly different from the database structure. For example, the BOM could include things which would actually map to aggregated views. Usually I first design the BOM according to the requirements, then I rework the database structure, including for example things which were not requested but which I feel will be useful later (timestamps, history tables, intermediate calculation steps, future developments...). </div><div class="gmail_extra"><br></div><div class="gmail_extra">One classical example: if I am asked to create a table with name and address, I actually create a table with the name and a separate table with the addresses, so that when (this always happens) the client discovers that people have more than one address, the database structure is ready, but also the code using that structure is ready too, or at least the modifications to that code are going to be simpler. In my example, the BOM still has the address included in the same object as the name, and the UI can behave as if this was physically true.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In a way, separating BOM from physical structure brings the same kind of advantages that structured programming does. Just as I can look at a piece of code from a higher level or right at the deepest code in the deepest routine, depending on my needs, I can look at the data from a wide point (usually using views or complex queries) or break the data in smaller parts and look at the physical data directly in the tables.<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Frederic Da Vitoria<br>(davitof)<br><br>Membre de l'April - « promouvoir et défendre le logiciel libre » - <a href="http://www.april.org" target="_blank">http://www.april.org</a><br></div>
</div></div>