{"type":"rich","version":"1.0","provider_name":"Transistor","provider_url":"https://transistor.fm","author_name":"Programming Tech Brief By HackerNoon","title":"A Unified Namespace Determines Your Historian Schema, Not the Other Way Around","html":"<iframe width=\"100%\" height=\"180\" frameborder=\"no\" scrolling=\"no\" seamless src=\"https://share.transistor.fm/e/512d4260\"></iframe>","width":"100%","height":180,"duration":820,"description":"\n        This story was originally published on HackerNoon at: https://hackernoon.com/a-unified-namespace-determines-your-historian-schema-not-the-other-way-around.\nDesign a historian schema for Unified Namespace architectures. Learn why narrow tables, surrogate keys, and relational namespaces outperform wide models.\nCheck more stories related to programming at: https://hackernoon.com/c/programming.\n            You can also check exclusive content about #unified-namespace, #uns-data-model-design, #database-architecture, #timescaledb-iot-schema, #isa-95-namespace-architecture, #surrogate-key-historian-design, #tag-management, #good-company,  and more.\nThis story was written by: @tigerdata. Learn more about this writer by checking @tigerdata's about page,\n            and for more stories, please visit hackernoon.com.\nMost teams design the historian first and connect it to a Unified Namespace later. This article argues the reverse: the UNS owns identity, so it should dictate the historian schema. That means storing tag identity in a relational namespace table with surrogate keys and keeping history in a narrow hypertable. The result: tag renames, hierarchy changes, and churn happen without rewriting history.","thumbnail_url":"https://img.transistorcdn.com/KhCapPSRkLGL2Xw8888yuChkNRWthaKapLYTvNdu4W4/rs:fill:0:0:1/w:400/h:400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9zaG93/LzQxMTY2LzE2ODM1/ODIzMzAtYXJ0d29y/ay5qcGc.webp","thumbnail_width":300,"thumbnail_height":300}