Location metadata storage: Difference between revisions

Line 9:

== Flexibility for what needs to be collected ==

There also might be information we have not even considered yet that we might need to track. So, we would want a flexible infrastructure. One way to do this would be something similar to the [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model] we use for the [[s_tmp table]] ~~that has the following:~~

There also might be information we have not even considered yet that we might need to track. So, we would want a flexible infrastructure. One way to do this would be something similar to the [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model] we use for the [[s_tmp table]]. See [[s_LocationData table]] for more info.

* location name (a physical location, so should not change) (the entity)

* Attribute (the place where we would ''name'' the thing we want to describe, e.~~g. "''bed number''")~~

* Value (the value for the named attribute, e.g. ''10'' in the case of beds)

* Start_DtTm (when did this entity-value combination become true)

* End_DtTm (when did the entity-value combination stop being true)

** End_DtTm is not needed for complete info, and in fact could become inconsistent, but it will make it easier for the [[~~Statistician~~]] ~~to use~~. ~~Since updates will be rarer than use, the difficulty is worth it~~

{{Todo

| who =Tina

| question = _Dev_CCMDB 1

| question = locationData _Dev_CCMDB 1

* do this high priority

| todo_added = ~~date the question was added~~ - ~~defaults to blank~~

| todo_added = 2022-02-09

| todo_action = ~~date the issue should be brought forward, or is due~~

| todo_action = 2022-02-09

}}

@@ Line 9: / Line 9: @@
 == Flexibility for what needs to be collected ==
-There also might be information we have not even considered yet that we might need to track. So, we would want a flexible infrastructure. One way to do this would be something similar to the  [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model] we use for the [[s_tmp table]] that has the following:
+There also might be information we have not even considered yet that we might need to track. So, we would want a flexible infrastructure. One way to do this would be something similar to the  [https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model Entity–attribute–value model] we use for the [[s_tmp table]]. See [[s_LocationData table]] for more info.
-* location name (a physical location, so should not change) (the entity)
-* Attribute (the place where we would ''name'' the thing we want to describe, e.g. "''bed number''")
-* Value (the value for the named attribute, e.g. ''10'' in the case of beds)
-* Start_DtTm (when did this entity-value combination become true)
-* End_DtTm (when did the entity-value combination stop being true)
-** End_DtTm is not needed for complete info, and in fact could become inconsistent, but it will make it easier for the [[Statistician]] to use. Since updates will be rarer than use, the difficulty is worth it
 {{Todo
   | who =Tina
-  | question =  _Dev_CCMDB 1
+  | question =  locationData _Dev_CCMDB 1
 * do this high priority
-| todo_added = date the question was added - defaults to blank
+| todo_added = 2022-02-09
-| todo_action = date the issue should be brought forward, or is due
+| todo_action = 2022-02-09
   }}