Hi Toddler, I added a few more templates to: http://schema.tiddlyspot.com
> A Client_Number field will be the same whether it is on the Client_Table > or the Account_Table. > Actually, I would think that in the client table it will probably be the primary key, perhaps *ClientKey* where as in other related tables it will not be, but rather be some *ClientRef* (pointing to the key in the client table). But sure, there can be a number of related tables all of which use *ClientRef*. However, you would need to have a great DB architect never to run into collisions, i.e. where a field name would always mean the same thing in all tables that have it. Also, similar to the template I gave you, it would be quite easy for *SomeTable.SomeField* to check if there is any *OtherTable.SomeField*, so the two are intrinsically linked without having to have to be a single tiddler. You could even make it so that *SomeTable.SomeField* would have a field *master:yes* that would inidcate that this is the master tiddler for the field *SomeField*. So, you don't have to specify the very same details for every other table that essentially implements the same field. However, the more you have of those the less normalized your DB presumably is. So, in general, you don't even want these kind of replications, unless perhaps performance dictates you to. > The *Business Description* or *Data Type* should not change, no matter > what table they are in. > You never know that, unless it's a strict rule in your architectural guidelines. > The things that might change are whether or not that table allows nulls > for that field or the fields origins, such as where it is ETLed from or > when it is in a view from another table. > Whatever the differences, as said, you can easily have one *SomeTable.SomeField* be the master, so that any *OtherTable.SomeField* would display a fallback from the latter for any field only defined at the master. Whether that is actually correct or not is a different issue, though. ;-) > Furthermore, while *SomeTable Notes* option that you suggested can be > used, it creates extra tiddlers. Using a one field to one tiddler concept > creates a simple conceptual parallel to the person filling out the data > dictionary. > Not sure what you mean here: Can you provide an example? Furthermore, using the transclude option allows an end user to print out > the definition for all the columns in the table and not just the field > names, which is what appears to happen with the tiddler you suggested. > You can easily extend the template to contain all kinds of details you may wish to display for those fields to a table, or for tables having the same field. > The template in that wiki is pretty awesome and should be commended, > however, the use of the same *field* tiddler in multiple *table* tiddlers > seems to be more versatile. > Again, nothing stops you from using my suggested naming conventions and still figure out what other table has a master definition for that fieldname. > The main crux of the issue is that when a field is used multiple times, > such as Client_Number, then it would be easier to read the Client_Table > definition without the Account_Table details getting in the way. > Not sure I understand this. Again, if there would be *SomeTable.SomeField* set to *master:yes*, then it would be easy to point to the master definition for that field... and indicate that it's actually some other table where that is primarily defined. > While they are still pertinent, they should remain minimized until needed. > Exactly, so *OtherTable.SomeField* may actually just be that, a tiddler with a title and nothing else. However, you'd be sure to have two tiddlers that indicate separation of concerns and you could easily have it so that *OtherTable.SomeField* actually has different details thant *SomeTable.SomeField*, should that be the case. Again, I thank you for your time and showing a different way on how to > accomplish this task. However, I am still on my endeavor on figuring this > out. The $reveal widget, should be the way to go. > I prefer the ListWidget. However, I do not understand how to set the state based on the tiddler > name. If you or anyone else has any guidance it would be greatly > appreciated. > You define a state namespace via macro, e.g.: <$vars state="$:/state/selected-table/$(currentTiddler)$"> ...your stuff using a non-qualified state like like <code><$text text=< <state>>>/></code>... </$vars> Or, if you need to be fancy about it: \define do-it() <$vars state="$:/state/selected-table/$(currentTiddler)$$(qualified)$"> ...your stuff using a qualified state like <code><$text text=<<state>>>/></ code>... </$vars> \end <$vars qualified=<<qualify>>> <<do-it>> </$vars> Best wishes, Tobias. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/43acc3e3-ad3b-4308-8b2a-9ffe9949944f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
