Patterns & OO Design - OO Design for Property type
We are currently in the design process for an application that will use an ORM and are trying to create an object model that will make the most sense for using the ORM to save data to the database. At this time, we will not be using the ORM to instantiate objects from the relational data.
The first set of information is for a property type, in particular a residential property. There are approximately 90 items of information about the property.
In regards to the number of fields for a single object, what is a good number to be around for a Hibernate mapping?
Right now we plan to have a Property, Listing, Rooms, Agent, Office tables and classes. Below is a complete list of all the data.
Any suggestions are greatly appreciated.
# 1
Property
Listing
StreetAddress
StreetNumber
BoxNumber
StreetDirPrefix
StreetName
StreetAdditionalInfo
StreetDirSuffix
StreetSuffix
UnitNumber
City
StateOrProvince
Country
PostalCode
CarrierRoute
ListingData
REAgent
REOffice
ListDate
ListPrice
ListPriceLow
ListPriceHigh
FinancialData
LeaseTerms
LeaseOption
TradeTerms
TradeOption
RentalTerms
RentalOption
RentalAmount
ExpirationDate
ShowingInstructions
ListingType
DisplayData
DisplayFlagListing
DisplayFlagAddress
Commission
Remarks
PublicRemarks
XXXInformation
ListingStatus
OriginalListPrice
ListingArea
StatusChangeDate
DaysOnMarket
ListingServiceName
GeographicData
Latitude
Longitude
County
Directions
MapCoordinate
URL
ModificationTimestamp
ListingID
Zoning
SalesData
XXAgent
FirstName
LastName
ContactInformation
OfficePhone
CellPhone
HomePhone
Fax
Pager
Email
URL
StreetAddress
StreetNumber
BoxNumber
StreetDirPrefix
StreetName
StreetAdditionalInfo
StreetDirSuffix
StreetSuffix
UnitNumber
City
StateOrProvince
Country
PostalCode
CarrierRoute
ListingServiceName
AgentID
NRDSMemberID
OfficeID
BrokerID
ModificationTimestamp
XXOffice
Name
ContactInformation
OfficePhone
CellPhone
HomePhone
Fax
Pager
Email
URL
StreetAddress
StreetNumber
BoxNumber
StreetDirPrefix
StreetName
StreetAdditionalInfo
StreetDirSuffix
StreetSuffix
UnitNumber
City
StateOrProvince
Country
PostalCode
CarrierRoute
ListingServiceName
AgentID
NRDSMemberID
OfficeID
BrokerID
ModificationTimestamp
ContractDate
ClosePrice
CloseDate
SchoolData
SchoolDistrict
PrimarySchool
ElementarySchool
MiddleSchool
JuniorHighSchool
HighSchool
TaxData
StreetAddress
StreetNumber
BoxNumber
StreetDirPrefix
StreetName
StreetAdditionalInfo
StreetDirSuffix
StreetSuffix
UnitNumber
City
StateOrProvince
Country
PostalCode
CarrierRoute
MailingAddress
StreetAddress
StreetNumber
BoxNumber
StreetDirPrefix
StreetName
StreetAdditionalInfo
StreetDirSuffix
StreetSuffix
UnitNumber
City
StateOrProvince
Country
PostalCode
CarrierRoute
TaxID
County
ModificationTimestamp
LegalDescription
OwnersName
AssessedValuation
PropertyZoning
ParcelMapURL
ParcelNumber
View
CopyrightNotice
Disclaimer
Community
CommunityName
ClubHouse
ExerciseArea
Golf
Tennis
RecreationalFacilities
SecurityFacilities
SeniorCommunity
HotTub
Pool
BoatFacilities
HorseFacilities
CommunityPark
PictureData
PictureID
ModificationTimestamp
URL
PictureCaption
PropertyType
Rental
Farm
Condominium
TownHouse
Bedrooms
Baths
BathsTotal
BathsFull
BathsHalf
BathsThreeQuarter
Subdivision
AssociationFee
LivingArea
Area
LotSize
Area
Dimensions
Length
Width
LotSizeRange
Parking
Garage
CarPort
OpenParking
CoveredParking
TotalParking
Stories
YearBuilt
Heating
Cooling
Pool
InteriorFeatures
ExteriorFeatures
Type
Style
Rooms
BedroomDetail
Bedroom
Area
Dimensions
Length
Width
BathroomDetail
Bathroom
DiningRoom
Area
Dimensions
Length
Width
LivingRoom
Area
Dimensions
Length
Width
FamilyRoom
Area
Dimensions
Length
Width
Basement
Area
Dimensions
Length
Width
Den
Area
Dimensions
Length
Width
OfficeRoom
Area
Dimensions
Length
Width
Kitchen
Area
Dimensions
Length
Width
GameRoom
Area
Dimensions
Length
Width
LaundryRoom
Area
Dimensions
Length
Width
TotalRooms
Occupant
Name
ContactInformation
OfficePhone
CellPhone
HomePhone
Fax
Pager
Email
URL
WaterFront
Fireplaces
FirePlace
FirePlaceFuelType
FirePlaceDetails
Roof
Exterior
Age
HorseFacilities
HotTub
TennisCourt
Inclusions
Floors
HardwoodFloors
EnergyInformation
ConstructionMaterials
DisabilityFeatures
SecurityFeatures
AnimalPolicy
AnimalsPermitted
PermittedTypes
WeightLimit
LotData
CornerLot
CuldeSac
GolfCourseLot
ViewData
CityLights
Mountain
Ocean
River
Lake
GolfCourse
Water
# 2
Unless I misunderstand what you have posted here, you would want a Room class with a type property. What's the difference between dimensions and length and width? Isn't area computed from the length and width or from the dimensions?
I thought part of the point of ORM was to help build a clean separation between the domain model and the relational model. Designing your classes for ORM seems kind of odd.
# 3
When would the tax address be different than the address of the home?
You have things in here that can be calculated from other fields. This is generally something to avoid. It mainly opens up opportunities for inconsistencies and you should not make the user enter in something that you can figure out from something else they have to enter.
# 4
Unless I misunderstand what you have posted here, you
would want a Room class with a type property.
Thank you for your suggestion. It doesn't fit our initial design.
Our main piece of information is a property. And the property has lots of information which describes the property, the listing for the property, and the entities associated with the listing.
For example, a residential property will have many rooms, such as living room, master bedroom, master bathroom, den, etc. Since there are many fields that describe the rooms of the property, we are going to create a Rooms class. Our Property class will contain a reference to the Rooms object.
We are trying to avoid having a single giant object with 70+ fields.
What's the difference between dimensions and length and
width? Isn't area computed from the length and width
or from the dimensions?
Thanks for pointing this out.
I thought part of the point of ORM was to help build
a clean separation between the domain model and the
relational model. Designing your classes for ORM
seems kind of odd.
There can be, and are many reasons as to using object-relational-mapper software, such as Hibernate.
We are using an ORM to streamline the persistence of business information and reduce the amount of hand-written JDBC and SQL code. This is non-trivial task for complex information. We want to ensure that our business object model design is very compatible and straightforward | friendly with the ORM functionality and friendly to our relational design.
We are designing the classes for the business application, for the ORM, for the relational database, and for the GUI all at the same time.
There are so many fields however, and since this is our first time using an ORM, i.e. Hibernate, we don't know how the ORM will handle objects with 30, 40, 50, 60 fields. And we are trying to be as simple as possible with the relationships. RIght now we can see the following objects:
Property, Listing, Rooms, Agent, Office
The Property object will still contain about 40 or so String fields and references to a Listing, Rooms, Agent and Office.
Is 40 still too many fields?
Any suggestions to a different design?
# 5
You have things in here that can be calculated from
other fields. This is generally something to avoid.
It mainly opens up opportunities for inconsistencies
and you should not make the user enter in something
that you can figure out from something else they
have to enter.
This is a great point. Thank you.
# 6
Unless I misunderstand what you have posted here,
you
would want a Room class with a type property.
Thank you for your suggestion. It doesn't fit our
initial design.
Our main piece of information is a property. And the
property has lots of information which describes the
property, the listing for the property, and the
entities associated with the listing.
For example, a residential property will have many
rooms, such as living room, master bedroom, master
bathroom, den, etc. Since there are many fields that
describe the rooms of the property, we are going to
create a Rooms class. Our Property class will contain
a reference to the Rooms object.
We are trying to avoid having a single giant object
with 70+ fields.
Right. That's why I was suggesting you have a Room class. Then Rooms or (Property directly) can contain a collection of rooms. I don't know how you would do it otherwise.
# 7
There are so many fields however, and since this is
our first time using an ORM, i.e. Hibernate, we don't
know how the ORM will handle objects with 30, 40, 50,
60 fields. And we are trying to be as simple as
possible with the relationships. RIght now we can see
the following objects:
50 properties should not cause any significant problems for Hibernate.But I think you are making life hard on your self by trying to denormalize the tables for no apparent reason. This will definitely make the design much less effective.
I'm not sure what your plan is for the rooms but unless you have a Room class and keep a collection of rooms, how are you going to store the room details for a house with 3 bedrooms, 5 bedrooms, 20 bedrooms. The same goes for bathrooms and even dens, kitchens, living rooms. I have a mudroom on my house. How will you represent that? Sunrooms? With a normalized design, you can often just add a new type to a reference table. If you denormalize, you will be forced to modify your database schema, code and often your hibernate mappings.
'Simplifying' the relationships is the most painful mistake in database design. It's pretty much guaranteed to make things difficult later.
# 8
50 properties should not cause any significant
problems for Hibernate.But I think you are making
life hard on your self by trying to denormalize the
tables for no apparent reason. This will definitely
make the design much less effective.
What makes you think we are trying to denormalize the tables?
We are trying to come up with an object design that (1) meets our business requirements, (2) is friendly for the ORM implementation, (3) will result in a normalized database suitable for direct SQL access and reporting and (4) satisfies our QoS requirements.
I'm not sure what your plan is for the rooms but
unless you have a Room class and keep a collection of
rooms, how are you going to store the room details
for a house with 3 bedrooms, 5 bedrooms, 20 bedrooms.
The same goes for bathrooms and even dens, kitchens,
living rooms. I have a mudroom on my house. How
will you represent that? Sunrooms?
In the sixth sentence of the first posting we specify that we will have a Rooms class and a Room table.
Right now we plan to have a Property, Listing, Rooms, Agent, Office tables and classes. A complete list of all the data for everything is above in the second post.
There is much more that just information about rooms however. We have information about schools, taxes and sales terms, energy information, listing information, etc.
# 9
50 properties should not cause any significant
problems for Hibernate.But I think you are
making
life hard on your self by trying to denormalize
the
tables for no apparent reason. This will
definitely
make the design much less effective.
What makes you think we are trying to denormalize the
tables?
Having 30-50 properties per Object and your response:
Thank you for your suggestion. It doesn't fit our initial design.
We are trying to come up with an object design that
(1) meets our business requirements, (2) is friendly
for the ORM implementation, (3) will result in a
normalized database suitable for direct SQL access
and reporting and (4) satisfies our QoS
requirements.
What was meant by this response?
Thank you for your suggestion. It doesn't fit our initial design.
I'm not sure what your plan is for the rooms but
unless you have a Room class and keep a collection
of
rooms, how are you going to store the room details
for a house with 3 bedrooms, 5 bedrooms, 20
bedrooms.
The same goes for bathrooms and even dens,
kitchens,
living rooms. I have a mudroom on my house. How
will you represent that? Sunrooms?
In the sixth sentence of the first posting we specify
that we will have a Rooms class and a Room table.
Have a Rooms table sounds like you would have one row containing all the rooms for each property. Maybe it's just a name issue but you should have one room per row.
Right now we plan to have a
Property, Listing,Rooms, Agent, Office tables and classes. A
complete list of all the data for everything is above
in the second post.
There is much more that just information about rooms
however. We have information about schools, taxes and
sales terms, energy information, listing information,
etc.
Again, this seems fairly denormalized. If you find that later you want to add another piece of info, you will need to add more columns and modify your code. Are you going to put the same school info in every propery in a given area? I've been through this kind of thing before. All the properties are added as columns to a table. Finally after many development cycles and explosive growth in the number of columns, you'll find that normalizing the database will be required anyway. You might as well save yourself the time and effort and do it the right way in the first place.
# 10
I also don't understand this:
We are using an ORM to streamline the persistence of
business information and reduce the amount of
hand-written JDBC and SQL code.
That's why most people use ORM.
This is non-trivial
task for complex information.
We want to ensure that
our business object model design is very compatible
and straightforward | friendly with the ORM
functionality and friendly to our relational
design.
What exactly do you think will make your design compatible with ORM? The most important factor in how smoothly ORM will go is how similar your domain model and database models are.
# 11
What makes you think we are trying to denormalize the
tables?
Having 30-50 properties per Object and your response.
I see. Your initial post seemed off base a bit. I had already stated that a Rooms object was in the works. The larger object is the Property object.
A Property object will contain a Rooms object. A Rooms object will be a collection-based class which will contain one or more Room objects. The Room class will be persisted and mapped to a p_property_rooms table (10 fields). Each record in the table to represent a Room object.
The Property object will contain a Listing object. The Listing object will contain data pertaining to the listing in the system. The Listing class will be mapped to a p_listingdata table (17 fields).
The Property object will conatin a Agent object. The Agent object will contain data pertaining to the listing and sales agents associated to the property. The Agent class will be mapped to a p_agent table (25 fields).
We are still working on the design. And imagine that we will have a common properties and property-specific tables/classes.
Are you going to put the same school info in every propery in a given >area? I've been through this kind of thing before. All the properties are >added as columns to a table. Finally after many development cycles >and explosive growth in the number of columns, you'll find that >normalizing the database will be required anyway. You might as well >save yourself the time and effort and do it the right way in the first >place.
Thank you. Again we are not going to have a single table but normalized tables.
The most important factor in how smoothly ORM will go is how similar >your domain model and database models are.
Thanks again. Since we are trying to come up with a design that makes the ORM mapping and simple as possible. And, we are trying to make a design that creates an effective relational design conducive for non-ORM related funcionality/features.
