无障碍开发
As described in SpringBoot’s website — “Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can “just run”.” In the current trend of moving towards weekly and even daily releases, doing away with boilerplate configuration and coding has become really important in helping you attain that sought after velocity. However, gains from a framework like SpringBoot can potentially be eroded by other speed blocks modern day developers have to deal with. One such speed block has to do with simply the amount of toil developers may have to deal with to get data in and out of their applications’ databases.
如SpringBoot 网站所述 ：“使用Spring Boot可以轻松地创建独立的，生产级的，基于Spring的应用程序，并且可以“运行”。 在当前朝着每周甚至每天发布的趋势中，取消样板配置和编码对于帮助您实现所追求的速度非常重要。 但是，像SpringBoot这样的框架所带来的收益可能会被现代开发人员必须应对的其他速度障碍侵蚀。 这样的速度障碍仅与开发人员为将数据进出其应用程序数据库而可能需要处理的工作量有关。
Prior to writing this blog post, I was originally planning to experiment with the difference between coding to MongoDB and to MySQL with Spring Data for SpringBoot based microservices. To get to that I first needed to setup a local database for each of the two technologies. Things were straightforward for me on the MongoDB side — I had installed MongoDB Enterprise earlier so I simply started mongod on a different dbpath to have a fresh instance. To populate a collection with some usable data, I ran mgenerate on a template I had in hand and piped the output to mongoimport. All these was done in less than 15 minutes.
在撰写此博客文章之前，我最初打算尝试使用Spring Data for基于SpringBoot的微服务对MongoDB和MySQL进行编码之间的区别。 为此，我首先需要为这两种技术中的每一种都设置一个本地数据库。 在MongoDB方面，事情对我来说很简单-我早先安装了MongoDB Enterprise，所以我只是在不同的dbpath上启动mongod来拥有一个新实例。 为了用一些可用数据填充一个集合，我在手头的模板上运行了mgenerate ，并将输出通过管道传递给mongoimport。 所有这些都在不到15分钟的时间内完成。
I then went ahead to install MySQL Community Edition together with MySQL Workbench. Both installed and started without a hitch and I created a schema easily with the Workbench. Next I needed to create tables and the relationships between them to accommodate a data structure in my code similar to this and this was where things started to get complicated.
然后，我继续与MySQL Workbench一起安装MySQL Community Edition。 无论安装还是启动都顺利，我使用Workbench轻松创建了一个架构。 接下来，我需要创建表及其之间的关系，以在我的代码中容纳与此类似的数据结构，这使事情开始变得复杂。
This is the sample customer profile data that I planned to build my experimental microservices upon
这是我计划在其上构建实验性微服务的样本客户个人资料数据
Warning: Speed block ahead
警告：超速行驶
I created my first table named profile in my customer schema. I started with id as my primary key… all good. Then I started populating the other columns and that’s when I had to make upfront decisions — what is the maximum value of “region”, how long a first and last name I should allow, should I allow null values, etc. I also got distracted by trivia entertainment along the way — anyone knows what’s the maximum length of an email address allowed… what about the longest city name in the world? It’s 254 characters for the former (see stackoverflow thread) and 21 for the latter (see here).
我在客户模式中创建了第一个名为profile的表。 我以id作为主键开始……一切都很好。 然后，我开始填充其他列，这是我必须做出预先决定的时候–“区域”的最大值是多少，我应该允许的姓氏和名字多长时间，是否应该允许空值，等等。我也分心了通过琐碎的娱乐活动-谁知道允许的电子邮件地址的最大长度是多少...世界上最长的城市名称呢？ 前者为254个字符(请参阅stackoverflow线程 )，后者为21个字符(请参见此处 )。
Null or not null… length of varchar… argh
空或不为空…varchar的长度…argh
After some huffing and puffing I got my first table configured and then I clicked on apply to create the table. The following error message popped up…
经过一番喘气之后，我配置了第一个表，然后单击“应用”创建表。 弹出以下错误信息……
How on earth did I end up with errors in my SQL script when its all generated by the workbench!?
当工作台全部生成SQL脚本时，我到底怎么会出错呢？
It turns out what I should have configured for id column should be “Auto Increment” so that it will be filled in automatically with a unique value. It is very interesting to note that the UI provided a checkbox for the “Generated” feature that seemingly requires additional inputs.
事实证明，我应该为id列配置的内容应该是“自动增量”，以便将其自动填充为唯一值。 有趣的是，用户界面提供了“已生成”功能的复选框，这似乎需要额外的输入。
After successfully creating the three tables (profile, address and policy) I needed to establish the relationship between them by creating relevant Foreign Key constraints. That in itself was quite simple… until again I had to decide upfront the right actions for “On Update” and “On Delete” events.
成功创建三个表(配置文件，地址和策略)后，我需要通过创建相关的外键约束来建立它们之间的关系。 这本身非常简单……直到我再次不得不为“ On Update”和“ On Delete”事件预先决定正确的动作。
Configuring the foreign key constraints involved having to make upfront decisions for the “On Update” and “On Delete” actions 配置外键约束涉及必须为“更新时”和“删除时”操作做出前期决策
With MongoDB, the document model was designed to bring about flexibility for both the developers and the business requirements. The flexibility starts when creating databases and collections where there is no expectations to have to know how the data would or should look like. Just give the collection a name and you are good to start inserting and querying your data.
使用MongoDB，文档模型旨在为开发人员和业务需求带来灵活性。 灵活性始于创建数据库和集合时，无需期望知道数据的外观或外观。 只要给集合起一个名字，就可以开始插入和查询数据了。
Give your collection a name and you are good to go 给您的收藏取一个名字，您就可以开始了
With the schema, tables and relationships created, the next thing to do would be to insert some data. This is where speed blocks rear its ugly head again. A typical SQL INSERT statement would have you declare a list of comma delimited values lined up exactly to the predefined column structure, not one more and not one less. Things get further complicated when you have to INSERT data into tables bound by Foreign Key constraints. You would need to ensure that the parent record is first INSERTed successfully so that you can reference the primary key. In this case I will need to create a record in the profile table first before I can create any in the address and policy tables. The amount of code needed to get you there simply does not help with your cause of writing quality software fast.You would probably want to use a ORM but it isn’t always configuration free (see example).
创建了架构，表和关系后，接下来要做的就是插入一些数据。 这是速度障碍再次抬起其丑陋的头的地方。 一个典型SQL INSERT语句使您声明一个以逗号分隔的值的列表，这些值正好与预定义的列结构对齐，而不是一个也不小于一个。 当您必须将数据插入到外键约束所约束的表中时，事情变得更加复杂。 您需要确保首先成功插入父记录，以便您可以引用主键。 在这种情况下，我需要先在配置文件表中创建一条记录，然后才能在地址和策略表中创建任何记录。 到达那里所需的大量代码根本无法帮助您快速编写高质量的软件。您可能想使用ORM，但它并非总是免费的(请参见示例 )。
With the MongoDB document model, you simply insert any valid JSON document by calling db.collection.insert({$DOC}). Relationships can be easily modelled in a single JSON document by way of nested documents or arrays (see example in screenshot below). This easily allows you to model the document after your classes or vice versa.
使用MongoDB文档模型，只需调用db.collection.insert({$ DOC})即可插入任何有效的JSON文档。 可以通过嵌套文档或数组在一个JSON文档中轻松建立关系模型(请参见下面的屏幕快照中的示例)。 这很容易使您可以在上完课后为文档建模，反之亦然。
Without a predefined schema, I can insert data of any shape and form (so long that its a well-formed JSON document) 没有预定义的架构，我可以插入任何形状和形式的数据(只要其格式正确的JSON文档即可)
While JSON is the choice of data representation in MongoDB, the database technology supports more than just strings and numbers as prescribed in the JSON spec. MongoDB supports data types such as Decimal, Double, Int32, Int64, etc. to afford you the precision you need when working with numerical data. The good thing is that you do not have to be too fixated on choosing the right data type at the onset because the document model allows you to insert data of different types even for the same field (column in SQL). This helps you to get started fast knowing that there are options to evolve your data structure as your application requirements evolve. After all change is the only constant.
尽管JSON是MongoDB中数据表示的选择，但数据库技术不仅仅支持JSON规范中规定的字符串和数字。 MongoDB支持十进制，双精度，Int32，Int64等数据类型，以为您提供处理数值数据时所需的精度。 好处是，您不必在一开始就选择正确的数据类型，因为文档模型允许您为同一字段(SQL中的列)插入不同类型的数据。 这可以帮助您快速入门，因为您知道可以根据应用程序需求的发展来发展数据结构。 毕竟改变是唯一不变的。
MongoDB document model does support data types MongoDB文档模型确实支持数据类型
(Conclusion)
Now at this point you might be wondering what’s the big deal in spending some time in defining a perfect schema for your precious data. After all that brings along the certainty that you expect of the applications that you create. The context here is speed. If you were doing daily releases, what would you rather release — working code or working schema? How much more of an impact there would be if somewhere along the way you had to alter you schema, tables and relationships? In modern application development methodology where agility is key because fast time to market is quintessential in business competition, there is simply lesser and lesser room for practices which requires waterfall-ish heavy up front design and expensive change requests down the road. In a small team that design conversation might be a matter of pulling a chair over to get things done in 20 minutes but in a traditional multi-stakeholder set up that more often than not ends up in a series of (sometimes frustrating) meetings.
现在，您可能会想知道，花一些时间为您的宝贵数据定义一个完美的架构有什么大不了的？ 毕竟，这带来了您所创建的应用程序所期望的确定性。 这里的上下文是速度。 如果您要进行每日发布，那么您宁愿发布什么-工作代码或工作模式？ 如果在您必须更改架构，表和关系的过程中某个地方会产生多大的影响？ 在现代应用程序开发方法中，敏捷性是关键因素，因为快速上市时间是企业竞争中的关键，因此实践空间越来越小，需要大量瀑布式的前期设计和昂贵的变更请求。 在一个小型团队中，进行设计对话可能是拉椅子以在20分钟之内完成工作的问题，但是在传统的多方利益相关者设置中，通常会导致一系列(有时令人沮丧的)会议。
Disclaimer: The postings on this site are my own and do not necessarily reflect the views of MongoDB.
