On Fri, Jun 26, 2015 at 9:47 AM, Michael Van Canneyt <[email protected]> wrote: > > > On Fri, 26 Jun 2015, Graeme Geldenhuys wrote: > >> Hi, >> >> Last night I was working on a relatively new project. This got me >> thinking... How do others tackle such a task? >> >> So here is my question: >> >> When faced with a new database related project, where do you start? Do >> you first design the database schema, then build the BOM (Business >> Objects) accordingly? Or, do you first design the BOM, then design the >> database schema to fit. >> >> Personally, most of my project were started by first creating the >> database schema. Don't ask me why, that is just what I did. Maybe it was >> because many of the tools I use, can write much of the boiler plate code >> for me, and they do that by querying a database structure. But I've been >> thinking that with my next project, I'm going to start with the BOM >> first, and see how it goes. I'm assuming the end result should be the >> same, no matter which part I tackled first. >> >> What's your thoughts? > > > I always start with the data. Almost all applications I ever wrote have > databases. > The data structure is in my experience always clear, simple. And thus I > consider it a good foundation for the rest. > > Things start to get messy when you start thinking about functionality. > So that comes next, and the business classes reflect functionality, and > consequently more susceptible to change. > > Luckily the persistence layers I use are flexible enough to allow any > mapping between data and business objects, > so the above approach has always worked for me. > > I'm tempted to say that working the other way round is bound to lead to > confusion.
Confusion... That depends if you work using a data-driven design or behavior-driven design. Marcos Douglas -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
