Null geometries - good or bad practice?

[MattPratap]

I am trying to create a solution for a customer who requires history of buildings.  There is a Buildings feature class, and I now want to create a BuildingHistory feature class with a relationship to Buildings fc.

The problem is that not all history records have a geometry (building outline). Some histories just have changed attributes (eg: the building purpose or name has changed).  Some histories have geometries (the building had additions and the outline changed).  Some have both.

Is it good practice to have a feature class with some features having a null geometry?  I dont want to have too many tables or feature classes to represent the combinations of history records with null geometries and actual geometries.

Are there any bad side effects to null geometries?

Using arc sde 10 with MS sql server 2008.

thanks

[VinceAngelo]

Sorry to make your life more difficult, but you actually have two choices -- null geometries
and nil geometries (the difference is that one is a true NULL, and the other is a shape with
zero vertices).  Plus, of course the unchanged geometry at that time, which would be easier
to render.  Whatever you decide, the ArcSDE model would support.

- V

[AJR]

Ditto Vince's comments about null vs. nil.

To answer your question there is nothing "wrong" with null and/or nil geomtries.  Scenarios like this are exactly why they exist.  That said, you may want to investigate alternatives to your methodology (e.g. you could time enable your layer rather than creating a history layer and having to write application code to manage the migration of features from one layer to another).