In the separation model, where do the different types of value lists reside.

I suspect the static, developer defined VL's and those from field values would be in the UI. What about the user defined VL's? Would they defined in the Data file and referenced through the UI?

(One small step toward separation, one giant leap for dramamine.)

I consider lists that I, the developer, create, to be a part of the interface, since they are predefined and static. Hence, I put them into the UI file. If I offer my clients the ability to modify a list, then it is their data, and belongs in the Data hierarchy. Things of this sort tend to represent some functional part of the data structure, and end up having their own tables and relationships.

For example, in a contact management system, I would put the listing for contact gender (static, I hope!) into the UI. A list of contact groups, which I would allow the client to manage and modify, would go into the Data file. There would be a CGroups table, with links to the CPeople table, among others.

HTH.

David

I consider lists that I, the developer, create, to be a part of the interface, since they are predefined and static. Hence, I put them into the UI file. If I offer my clients the ability to modify a list, then it is their data, and belongs in the Data hierarchy. Things of this sort tend to represent some functional part of the data structure, and end up having their own tables and relationships.

For example, in a contact management system, I would put the listing for contact gender (static, I hope!) into the UI. A list of contact groups, which I would allow the client to manage and modify, would go into the Data file. There would be a CGroups table, with links to the CPeople table, among others.

HTH.

David

I consider lists that I, the developer, create, to be a part of the interface, since they are predefined and static. Hence, I put them into the UI file. If I offer my clients the ability to modify a list, then it is their data, and belongs in the Data hierarchy. Things of this sort tend to represent some functional part of the data structure, and end up having their own tables and relationships.

For example, in a contact management system, I would put the listing for contact gender (static, I hope!) into the UI. A list of contact groups, which I would allow the client to manage and modify, would go into the Data file. There would be a CGroups table, with links to the CPeople table, among others.

HTH.

David

I came to the same conclusions as you have. I appreciate the positive reinforcement.

Re gender, I came across two new terms lately: "transgender female" and "transgender male" for those that have undergone sex change operations. I don't know, however if the term male or female refers to the pre or the post surgical state.

Have fun while it lasts.

I came to the same conclusions as you have. I appreciate the positive reinforcement.

Re gender, I came across two new terms lately: "transgender female" and "transgender male" for those that have undergone sex change operations. I don't know, however if the term male or female refers to the pre or the post surgical state.

Have fun while it lasts.

I came to the same conclusions as you have. I appreciate the positive reinforcement.

Re gender, I came across two new terms lately: "transgender female" and "transgender male" for those that have undergone sex change operations. I don't know, however if the term male or female refers to the pre or the post surgical state.

Have fun while it lasts.