Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Edward Chen:
Dear Lasse,
1. what is "ORM tool" ?
2. could you give me more details? just give me a little simple example.
Thank you very much.
Originally posted by Ilja Preuss:
Database tables are not objects and their design is driven by different forces, so it doesn't make much sense apply OO design principles to them.
What you should do is design your data model, driven by data needs, in parallel design your object model, driven by object oriented needs, and *then* provide the mapping between the too.
See http://www.agiledata.org/essays/drivingForces.html
Originally posted by Murasoli Maran:
Castor
Originally posted by Murasoli Maran:
now i always start with a good database design.That's much better that creating domain model and object model and starting with it.practically the base should be the database design for an application which use database persistance.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Ilja Preuss:
See http://www.agiledata.org/essays/drivingForces.html
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
I have to disagree with you here. While I acknowledge that the database is perhaps the most critical part of your system regarding performance tuning, let's not forget that persistence is just infrastructure. Your customer is not paying you for persistence -- he's paying you for features. Yes, one of those is probably that all application data should be persistent, but if you raise the database design to be the most important model you have you'll easily dig yourself into a hole labeled maintenance nightmare. A good domain model let's you move quickly when new features need to be incorporated into the system and let's you design your database (or other means of achieving persistence) as you see best.
Your customer is not paying you for persistence -- he's paying you for features.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
42
Originally posted by Jeroen Wenting:
And therefore it makes a lot of sense to design the database first. If you get the database hammered out and working correctly it will be less likely to need major changes afterwards during application development.
If you start with the application and design the database (or rather not-design the database) to match your ever changing needs for persistence as you go through the development of the application the database is more likely to become a mess of data duplication and redundancy.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Jeroen Wenting:
He points out, quite correctly, that database refactoring is much more difficult than code refactoring, both because database refactorings must preserve what he calls "informational semantics" as well as behavioral semantics, and because databases tend to be coupled to a lot more stuff. He goes so far as to say that database refactoring "is incredibly difficult in practice".
And therefore it makes a lot of sense to design the database first. If you get the database hammered out and working correctly it will be less likely to need major changes afterwards during application development.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
I do think that the Scott Ambler links - or at least the database refactoring link - miss an important implication of a point he himself makes.
He points out, quite correctly, that database refactoring is much more difficult than code refactoring, both because database refactorings must preserve what he calls "informational semantics" as well as behavioral semantics, and because databases tend to be coupled to a lot more stuff. He goes so far as to say that database refactoring "is incredibly difficult in practice".
But then he goes ahead and recommends refactoring freely in small increments.
It seems to me that if refactoring is much more expensive for databases, it makes sense to take steps to avoid having to do it as much.
In particular, it might be worthwhile to spend a little more time getting the schema closer to correct at the beginning, as he mentions data professionals are wont to do - especially since, while database refactoring is more expensive, initially writing a database's worth of schema and scripts is much cheaper than writing an application's worth of code.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Murasoli Maran:
I agree with you exactly. [...] now i always start with a good database design.
That's much better that creating domain model and object model and starting with it.practically the base should be the database design for an application which use database persistance.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
On the other hand I've often worked on systems where the database (either by design or by accident) also forms a key communication protocol. Several applications with different change rates, different development teams, and different technologies rely on SQL access to the same database.
Originally posted by Warren Dew:
So your reasoning is that you'll encounter less change in requirements during the project if you start with the database design? Surely that can't be the case...
I think the reasoning is that the vast majority of code refactorings aren't responses to changes in the requirements, but are instead responses to changes in the implementation.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Frank Carver:
I agree that this is true in a lot of "stand-alone" applications. On the other hand I've often worked on systems where the database (either by design or by accident) also forms a key communication protocol. Several applications with different change rates, different development teams, and different technologies rely on SQL access to the same database.
[...]
In situations such as this, you simply cannot change the database structure without preserving backward compatibility.[/QB]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
I think the reasoning is that the vast majority of code refactorings aren't responses to changes in the requirements, but are instead responses to changes in the implementation.
In fact, some people consider that part of the definition of refactoring - refactoring is when you change the code around to clean it up specifically without changing the behavior.
By that definition, you should almost never have to refactor a proper database schema, since if you start out with a proper database design, and maintain the normal forms whenever it gets changed, it never gets dirty in the first place.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
And my experience is indeed that if people approach the database as being as mutable as code, "a mess of data duplication and redundancy" will be the result.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
Interesting. I usually take just the opposite approach - I first do the refactoring needed to support making the changes cleanly, then I make those changes. But I agree that either way works, for code.
Making a database schema work - including being free of data duplication, or more explicitly, meeting third normal form - automatically makes it pretty.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
Why does a database schema need to meet third normal form to *work*?
Because a database that has duplicated locations for the same data has the following feature: you can put the data in, and then you can take the data out, and you can get something different from what you put in. That, to me, is not just "not pretty" - it's "not working".
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Warren Dew:
Denormalizing a database - at least for third normal form, I can't vouch for sixth and seventh normal form - is cognate to removing locks between contending threads. Yes, it can result in faster performance. On the other hand, the resulting code is arguably broken.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Junilu Lacar:
For example, one symptom of this type of leaky abstraction that I have learned to look for is the existence of a type field in the business objects. This "smell" can indicate that the class that has "types" should be refactored into subclasses, one subclass for each "type".
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
For some applications, hiring someone who doesn't understand databases and just tosses a bunch of fields together may indeed be "good enough"
However, in any project where it makes sense to take the effort to get good programmers who can write quality code, I have a hard time believing that it makes sense to accept inferior quality in the database.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Warren Dew:
Databases are about the data, code is about doing stuff with the data. Duplicated data in a database is like duplicated threads in a program. In my experience, when I fire off two threads where I really only wanted one, the result is generally unexpected behavior.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
<a href="http://www.methodsandtools.com" target="_blank" rel="nofollow">www.methodsandtools.com</a>
Originally posted by Stan James:
On the other hand starting from data is dead simple, fast and hard to resist for stateless CRUD applications that project a database onto the screen with little behavior. Use the style that fits the task.
Originally posted by Murasoli Maran:
Remember,i am talking abt database driven applications.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
a wee bit from the empire
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|