|
#1
|
|||
|
|||
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 |
#2
|
|||||
|
|||||
Re: ashwken's Data Structure
Quote:
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. Quote:
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). Quote:
Quote:
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. Quote:
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. Last edited by ashwken; 01-08-2008 at 11:51 PM. |
#3
|
|||
|
|||
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. Quote:
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 |
Thread Tools | |
Display Modes | Rate This Thread |
|
|