Posted
on Aug 10, 2011
(permalink)
I would like to briefly describe my use case so it may be considered during any product changes, which may be slightly more complex (this is just one example).
I utilize a [User] object (and table) that can login to my application. I also utilize an [Employee] object (and table), which are considered a resource within the application (they can be assigned work, etc.). In some cases there may be [Users] who are [Employees], but some [Users] are not [Employees]. (They can fill out requests and do other tasks, but do not work for the organization and so cannot receive assignments.) There are some [Employees] who are [Users], but there are also [Employees] who are not [Users]. (They are considered resources, but cannot log in to the system; supervisors will print out assignments and hand them to them). This makes for a dual sided 0-1 relationship, and I would like to navigate in both directions, after checking for a null value. In my current implementation, both [Users] and [Employees] have a unique autonumber primary key, and I only keep a single foreign key, [UserId], in the [Employees] table.
This design was chosen because it was desired to track additional items (and enable additional functionality) when an employee is logged in vs. a non-employee user.
Anyway, the point of this is to make sure the maximum flexibility is built into the system as Telerik implements changes in their product. I also noticed that below the article (by title at least) specifically addresses One-To-One, and not Zero-To-One.
Thank you.