使用以下代码段:
(fromIntegral 100)/10.00
使用Haskell '98标准前奏,如何用两位小数表示结果？
谢谢.
我需要存储一组实体,其中有几个专用版本.它们具有一些共同属性,但专用属性包含特定于该实体的属性.
数据存储是一个关系型DBMS,这不是讨论:-)具体来说,它是Microsoft SQL Server 2005.
我可以轻松地为公共属性创建一个表,然后为每个专用版本创建一个表.但是,以后可能需要将新实体添加到解决方案中,并且我不希望同时维护对象模型和数据库模式.
另一个想法是创建一个表
reading(<common properties>, extended_properties)
并且该extended_properties字段是扩展属性的某种序列化.我在想JSON或XML.我很可能会使用ORM框架,但我还没有决定.无论哪种方式,来自的专用实体的对象表示都reading可以公开{extended_property_name, value}包含来自该extended_properties字段的解析的键/值对的字典.
从这个http://msdn.microsoft.com/en-us/library/ms345117(SQL.90).aspx我收集XML字段,结合这些的模式,在DBMS中给出了类型化XML的概念.此外,涉及extended_properties字段中的XML内容的查询也可以考虑这些.
对我的解决方案建议的反馈,主要是具有reading扩展属性的表和序列化的建议.
此外,我意识到这是关系DBMS与基于键/值的商店相比的局限性之一.但是,肯定必须有一些建模技术来适应这种情况.
非常感谢任何反馈!
在我正在开发的这个应用程序中,域名围绕着电器.该实体有几个专门版本.可以将设备提交给应用程序,这可以通过使用数据传输对象的Web服务进行.
虽然这很有效,但我现在正在考虑从几种基于文本的文件格式导入设备.考虑此工作流程:
现在,应用程序服务可以有一个具有以下名称和签名的方法:ApplianceService.Register(string fileContents).我认为目录观察者服务将使用此服务方法并将其传递给文件的全部内容.然后,应用程序服务将协调解析.解析文件的内容并将其转换为完整的设备实体涉及几个步骤.现在,我的问题是:
问题:这是正确的,还是解析逻辑应该存在于目录观察器服务中？每种类型的文件格式是一种域的一部分,但话又说回来,其实并非如此.在将文件从任一格式解析为实体之后,实体将永远不会知道它曾使用该格式表示过.如果解析逻辑应该存在于观察者服务中,我会将新设备作为数据传输对象传递给注册服务.
我想我关心的是设备在进入我的应用程序之前应该如何表示(使用应用程序层作为入口点).从Web服务提交设备时,我会传递一系列设备数据传输对象.这与获取可能奇怪格式化的文件并将其解析为数据传输对象不同,因为从Web服务请求到数据传输对象的映射非常简单,而不是那么复杂.
对此的任何想法都非常受欢迎.