Level 11
I would make all optional fields nullable and then do a find and replace in the database for "CloseDate" of 0000-00-0000 and replace with NULL.
Apr 21, 2018
4
Level 5
Best practice for migrations and null?
I'm creating my real estate site and am very new to this but loving it. I'm pulling data down from my local board of Realtors and they have fields like "CloseDate" for properties. However, if the property hasn't closed, that field is the old MySQL format of 0000-00-0000 or whatever that was. Then, I have fields that are like "GuestHouseSqFt" but if the property doesn't have a guest house, that's empty.
With that being said, do I just go through each field and mark them in my migration as ->nullable()?
What do I do about DATETIME fields?
Level 67
I interact with a lot of rets servers. One thing I'll say is they are all extremely inconsistent with their data. It seems just about all fields are optional to the MLS's. Dealing with data is a pain. Like a phone number field can be a phone number, or a ton of text. They can just enter whatever they seem to want. Just about all fields are nullable in my db for this reason. I agree, check incoming dates and convert 0000-00-00 to null.
And I'd use the tax assessors number for the lot as the primary id, since listing id/mls id can change, but the assessors number won't. It makes tracking property history a lot easier as well, if you do that sort of thing.
Level 47
For me personally I just assume any field should be null by default unless there is a reason for it not to be.
Level 5
@Cronix You're right. It is wildly inconsistent. However, one thing they do that works is put a field called matrix_unique_id that is always there and accurately identifies a property. There's the MLS number too but the unique id is better to use.
@spekkionu Thank you. I think that's what I'm going to do.
Please or to participate in this conversation.