上周六，写了第一篇博客《订餐系统之权限设计》，在此感谢那些鼓励、关注我的园友们，更要感谢那些提出宝贵建议的朋友们。看了你们的评论，才真切的感受到： 朋友们的评论往往会让文章更有看点 。上篇文章中 郑明、人生就是赌 等几个园友的留言让我对我们系
上周六，网站空间，写了第一篇博客《订餐系统之权限设计》，在此感谢那些鼓励、关注我的园友们，更要感谢那些提出宝贵建议的朋友们。看了你们的评论，才真切的感受到：朋友们的评论往往会让文章更有看点。上篇文章中 郑明、人生就是赌 等几个园友的留言让我对我们系统的权限优化有了方向。当然，这样的优化肯定不是一天两天的事，做技术的朋友应该都知道：一个难题经常啃啃，美国服务器，某天也许就有了好的方案了（近段时间啃掉了几个2、3年前未处理好的的问题，才想起初中数学老师让我们经常啃一些竞赛题的良苦用心），今天的文章说的就是一个从2010年就想优化，但一直未优化好的功能，也从 幸福框架的评论中，看到了他的博客，更是从他博客的留言中，找到了处理：按日期+6位顺序号生成订单编号（主要处理并发的情况）的方案，之前有客户要这样生成订单编号，我只能回复实现不了，因为当时只知道，每次获取最大的订单编号，处理不了并发的情况，惭愧。
关于这个标题，我还是交代下背景吧。这个问题从2010年第一次实现时，就觉得当时那种方案太差了，自己都看不去，只因没有别的办法，从那以后，每每得空，就拿出来琢磨下，现在这个方案也许还有不少问题，也希望各位指点下。我们是做订餐系统的，主要实体就是商家（有坐标）和用户（有坐标）。所以就有这么个需求，香港空间，返回距离N公里内的商家，按距离从近到远排序。先看下，数据库设计吧，如图（1）：
