由于（a）您正在使用的信息本身似乎是非常宝贵的组织资源，并且（b）数据量将非常可观，因此我决定（c）在以下其中一个基础上建立关系数据库主要的SQL平台。
当然，从非常普遍的角度来看，这需要三个基本因素：
一种明确定义的概念模式，其中必须精确识别并标记事物的原型，即与您正在使用的业务环境相关的实体类型（包括其属性和相互关系）（例如，塔楼和您提到的传感器）。
如您所知，这一点需要与业务专家建立持续有效的沟通。
通过表（即数学关系）保持具有正确分隔的列的逻辑布局，该表具有适当的列名和类型（即关系属性）以及所有相应的约束条件，以确保数据符合在上一层确定的所有规则。
因此，正是在这里关系模型的巨大力量发挥了作用（尽管它的优点在其他抽象级别上具有积极的影响）。
一种物理布置，例如，可以提高“动态”逻辑数据操纵操作的执行速度并保证逻辑约束。
由于关系模型提供了物理数据独立性，因此数据库管理系统（为简便起见，DBMS）可以在此级别提供任何类型的结构，而不仅限于索引，以支持逻辑定义。对于领先的SQL平台，是的，这通常意味着精确地基于数据库特定的查询趋势来建立索引策略，并且您针对某些可能的配置提出了非常有趣的考虑因素，但是却不知道具体的情况。具有准确性的信息必需品，在这方面提供具体建议是不合适的。
其他值得评估的要素是，例如，升级网络基础结构以增加带宽，启用正确的服务器配置（从硬件和软件角度）等。而且，并且仅当从业者具有足够的资格时，他或她甚至可以修改所选DBMS的源代码（自然在开源环境中更可行）。
通过这种方式，您突出了以下方面
- 管理和检索塔/传感器配置，以进行数据分析。
- 通过传感器或时间间隔进行数据可视化以进行气象观测。
- 为客户提供可靠和持久的数据资源/数据集，以比较模型和传感器的性能（可能需要进行一些后处理才能以所需的格式交付？）。
将会得到很好的解决，因为您将能够轻松地声明查询，例如以非常有意义的形式获取信息。例如，您可以获取与
- 由SensorNumber标识的传感器
1750，安装在31Date 1 June 2017和Date 之间的TowerNumber标识的塔上27 June 2017。
此外，由于（1）在关系数据库中的数据在逻辑上来讲管理集基于所述操作的辅助关系代数，和（2）的不同的SQL引擎在物理上优化的（一些超过其他）组处理，例如
- 比较集a与集b ;
- 将set c与set d连接；
- 通过对集e的限制获得子集f ;
- 从n个集合相交中生成n个子集；
- 从集合f中投影n个属性
- 从集合z检索信息，该信息是集合x与集合y的并集的结果；
- 等等。
实际上，数据处理的可能性是巨大的-证明了关系范式的无与伦比的通用性-因为您不仅可以使用基表（用CREATE TABLE … ( … );语句声明的表），还可以使用派生表（通过SELECT …;操作表示的表，有时固定为VIEWs） 。换句话说，您可以（i）基于（ii）在（iii）单个基础关系构造（即数学关系）上运行的先前数据结构来表示新的数据结构。
显然，关系数据库的基础表和列的排列可以改变，并且（a）当（b）在本指南中认为值得跟踪新的实体类型或实体类型属性时，可以将新的基础表或列并入其中。相关的业务环境。换言之，无论初始结构也不关系数据库的开口约束预计是静态的或不可变的。此外，当出现新的信息需求时，从一开始就进行适当组织的数据库往往更容易修改。
出于上述考虑，必须在数据库逻辑级别声明性地生成适用集的逻辑格式。集合的图形或演示格式设置（例如，使用的着色或字体）必须依次通过一个或多个应用程序的代码进行处理（是的，主要是以过程方式，也许借助对象面向对象的框架，HTML等），以使此类集的访问和展示变得用户友好。当然，您也可以使用与数据库连接的报告软件。
相关数据库的建模
既然你将与工作传感器数据（其中，除其他功能，通常涉及的形状信息的时间序列），你会发现帮助多个数据库设计和整体管理原则包含两个特殊的答案，通过@PerformanceDBA，题为：
关系，平面文件和NoSQL方法
在关系模型由埃德加·弗兰克·科德博士，虽然出版于1970年，真正的仍然是最现代和优雅的方法（基于逻辑和集合论），以应对数据管理的问题。反过来，不同的SQL DBMS则是关系理论中提出的系统的最流行的近似值（尽管不完全兼容，但确实非常强大），其中一些已经过优化（例如，关于它们的物理-级别的机制）甚至几十年来。此外，主SQL平台当然可以（并且将能够）非常有效地与最新的存储（例如硬盘驱动器）和处理（例如CPU）技术一起使用。
当基于强大的DBMS构建时，在概念，逻辑和物理级别进行适当设计的关系数据库将绝对成为一种自包含，自描述和自保护的资产，其（1）是值得信赖的，（2）提供了快速响应，正如您所知，有两个方面非常重要。
平面文件
因此，以下主张
有人告诉我，使用平面文件的理由是，他们认为关系数据库会占用过多的开销。
很容易被丢弃，因为平面文件方法将是：
- 前科学
- 对于大量数据而言远非最佳选择；
- 太麻烦了
- 与应用程序相关的（并且您将不得不手动实现适当的DBMS本机提供的大多数功能）；
- 它的性能很容易被破坏；
- 等等
至少可以说，“更方便的”关系时尚：
- 会提供较大的可扩展性（它与物理级别无关，因此您可以根据需要增强底层的物理机制）；
- 会带来一种简单的样式来操作数据（通过抽象操作），并且
- 可以同时使用多个应用程序（例如，一个或多个移动应用程序，和/或一个或多个Web应用程序，和/或一个或多个桌面应用程序等）。
但是，如果您选择使用平面文件，则应评估使用Awk之类的强大实用程序，尽管该实用程序不是DBMS（并非如此设计），但它提供了处理文件，记录，字段等的便捷资源。有关该主题的更多信息，请参见《 GNU Awk用户指南》。
NoSQL
“非结构化数据”及相关术语
根据他们的宣传，使用NoSQL DBMS的最初理由是它们应在涉及处理“非结构化数据”的业务领域中使用，因此需要提出以下问题：
在这方面，必须说数据本身就是结构化的；如果它没有结构，那么它将是毫无意义的，因此，这样的事情（i）不能被视为数据，并且（ii）不值得管理。因此，“非结构化数据”是一个矛盾且不幸的表述。
这些上下文中的其他短语是“半结构化数据”。该短语表示存在“部分”或“一半”结构的数据，因此根据上一段，只有结构化的“部分”或“一半”可以是实际数据，其余的“部分” “半”或“一半”只是没有形状的东西，因为它缺乏结构，因此不能称为数据。
遗憾的是，在NoSQL营销中发现的另一个典型术语是“多态数据”。如果所说的术语表示“具有多种不同形式的数据”之类的东西，那么实际上它就是普通数据，它一如既往地以许多不同的形式出现。而且由于它具有许多不同的形式，所以它呈现了许多不同的结构，因此，这种“种类”的数据没有什么特别的。
不用说，数据和数据结构始终容易受到更改的影响，因此在这方面也没有异常。
数据量增长
显然，多年来，通过计算机系统管理的信息量确实在增长，并且由于每天都在建立新系统，因此随着时间的流逝将呈指数级增长，但这与事实无关信息本身的结构。
缺乏全面的理论基础
NoSQL系统（存在不同的类别，例如基于文档和图形的类别）的一个关键限制是，尽管市场上有很多产品并被标记为“现代”产品，但当前的产品都没有合理的理论基础（如果有的话）支持适当的DBMS的三个最重要要素的每个要素，即用于数据的工具（a）定义，（b）操纵和（c）压缩。因此，NoSQL方法实际上暗示了对古代时代的回归，在古代时代，对数据的处理是临时的，不合理的，并带来了所有不必要的复杂性。
如今，图形系统已包含在“ NoSQL”范围内。这些软件产品邀请通过对两个不同结构的操作来管理数据：节点和关系（它们再次与术语“非结构化数据”相冲突），并且它们在“ NoSQL”组中脱颖而出，因为它们有数学基础。但是，图形产品非常类似于网络平台，自几十年前就被认为已经过时了（明显的缺点是，如上所述，它们需要两种结构来表示数据，而关系DBMS（根据信息原理）只需要一个）。
即使与大多数SQL DBMS的起源相比，不同NoSQL系统的创建在时间上较新，但NoSQL产品所基于的大多数概念实际上都是原始的。
大多数情况下，应在以下情况下使用NoSQL程序：
- IT人员缺乏确定（或适当确定）感兴趣数据的结构所需的技术技能（例如，由于其复杂性）；和/或
- 组织不能为现有员工提供适当的教育和培训，或者不能雇用拥有所需教育和培训的新员工；和/或
- 当数据的完整性和一致性不是特别重要时；和/或
- 当将相关数据与要求高精度的任务关键型系统的数据混合时，是无法预期的。
但是，即使在创建相关系统之前未定义所讨论数据的结构，也将需要一个或更多的人来完成。
- 发现上述结构，
- 丢弃所有周围的“干扰”并
- 收集并链接适当的数据
在数据库和应用程序进入生产阶段以便能够从投资于项目的所有资源中获得最大收益之后，数据结构的描述是一项不可回避的任务，必须尽快完成或更高版本。
因此，尽管有可能采用NoSQL方式，但绝对应考虑到前面提到的所有因素。
最强大的方法
相比之下，以关系方式（即，后面具有通用范例）来满足业务环境的信息需求，则提供了以下可能性：（1）从一开始就以其自然结构管理数据，从而简化了与其他数据源的集成。 （2）通过操纵单一工具（如前几节所述），产生了新的可信赖的结构，该结构具有强大的科学基础。
根据对有关场景的描述，您已经根据相关的组织需求确定了特定的结构，因此，我建议要求业务领域专家对其进行验证。接下来，我建议您利用（i）关系模型提供的构造（关系，约束和操作）来处理所述结构和相应的数据，以及（ii）您选择的SQL DBMS很有可能提供了可以满足当前需求并提供未来可扩展性的非常有效的物理工具。