ashwken's Data Structure
 

I'm intrigued by ashwken's meticulous database design.
Questions:
1. What's inside the _System Items and _User-Defined KW folders?
2. Does _user-Defined KW consist of Search Info Items?
3. How do you create the _User-Defined KW contents, programmatically or manually? In particular, how are the KWs generated?
4. Is New Folder a derived template or just plain Info Item?
5. Given that two urds were offered by you, you appear to be more inclined to mulitple-urd database design, aren't you?
6. How do you generate the account numbers such as 100524 without duplicates? Are the account number generated programmatically or manually (ie, visual lookup)?

Sorry for more questions. Kinook creates a highly innovative tool, but it take a determined user like you to push the envelope of the technology with ingenuity and practical experience.

Armstrong

Re: ashwken's Data Structure
 

These questions stem from the screen shots posted to this thread:

http://www.kinook.com/Forum/showthre...&threadid=3361

The Folder _System Items is a user created folder, something that I create after starting a new urd, it contains the default UR Items created by the File | New function. It allows me to move these default Items out of the way while I work on development of the new database. Generally, I end up deleting this folder at some point.
The remainder of the questions pertian to User-Defined Keywords and creation of a "dummy" Item discussed in this thread:

http://www.kinook.com/Forum/showthre...&threadid=3311

The screen shots mentioned above (threadid=3361) were made from an earlier version of the Habitat for Humanities database, the Folder _User-Defined KW was eventually deleted (finished up the work on my home system).

Yes, it's a derived Template - Folder; actually it's a bit of trash that got deleted.

Yes, generally I'll create a database to address a specific task, interest, or answer a group of questions. In some cases I try to keep in mind that the databases could be merged into a larger more general database at some point in the future.

Also, every new project that I work on teaches me more about UR, my methods are still evolving, and I still haven't fully translated what I learned about data normalization into the UR framework and parlance.

This refers to the original screen shots uploaded for this thread (threadid=3361), which have since been replaced.

The account number that you refer to (100524) is a Multiple Listing Number (MLS), and the Item represents a Real Estate Listing held by the firm. The MLS No is generated when entering a Listing into a MLS System.

The Item Title for a Listing Item takes the following form:

(MLS No) - (Seller Name) - (Listing Address)

Each "part" of the Item Title is also an Attribute. The Item Title is user created (it would be nice if I could define the Item Title from a calculation).

The children of a Listing Item are the typical things (Items) used to track a piece of inventory: pdfs of legal docs, images, link to Seller Contact Item, correspondence, etc...

This database also tracks Advertising Events-Costs for a Listing, and Lockbox and Signage assignment. I haven't worked in a Transactions (Sales) sibling yet.

I have a separate db for Lead Tracking, different set of needs.

I am not convinced that my methods are totally sound, nor is my understanding complete, take it all with a grain of salt.

ashwken,

I'm grateful for your generosity of expounding the seemingly mysterious indecipherable database structure. In light of your revelation, now I understand the dynamics and evolution of a live UR database construction process. In particular, the lessons I learn from you include but not limited to:
1. Mixing both the design and production data into a single database at least during the initial stage. Such approach promotes clarity and productivity through rapid cross reference.
2. The children of an Info Item, in this case, MLS listing items, consist of heterogeneous data types. That's amazing.

Due to UR's unconventional design, for all practical purposes, the normalization in accordance with Edgar F. Codd is no longer relevant and applicable here, IMHO.

I believe your down-to-earth approach, just like GTD, can be applied to most UR users with success.

Again, thanks for taking valuable time to reply my post.

Armstrong