我的任务是为我目前的工作开发一个新的零售电子商务店面,我正在考虑用RoR来解决它A)用我有限的Rails知识建立一个“真正的”项目,并且B)快速管理转机和反馈(他们希望尽快完成这项工作,他们的最后期限是相当不切实际的 - 我说几个星期从零开始到工作模式,所以他们可以开始用SEO / SEM推销它,我哄骗你不,“视频博客”,因为我的老板听说这是未来。)
我们确实有一个数据库结构,但是它非常可怕并且没有押韵也没有理由被抛在一起,所以我将在很大程度上忽略它并从头开始创建一个新的数据库;但是,我有需要加载到应用程序中的现有数据(就像我说的,它是一个电子商务应用程序,我们有产品数据)。我需要将这些数据按到一个可用的格式,因为我们的供应商向我们提供了神秘的,缩写的列名称,并且它高度非规范化,特别是在类别中(我之前发布了一个关于它的问题 - 基本上类别表有六个字段,每个类别/子类别一个,如果该类别不适用,其中一些是空白的。
有两个主要问题让我第二个想法:
正如我所说,数据需要放入“适当的”数据库模式;我不能只是按原样加载它。我对它的良好数据模型有一些想法,但我的分析还没有完成。最终会有大量的连接表将各种东西链接在一起(例如products_categories,products_attributes,products_prices)等,这些表格不是通过ID而是通过SKU链接产品(见下文)。
所有东西都已经为它生成了一个ID,但是我添加的任何新东西都需要自动生成一个;我怀疑这对任何成熟的RDBMS都有问题,但我知道Rails喜欢自己生成ID。此外,几乎所有与产品相关的表都由SKU链接(并且在供应商提供的数据中实际上是由前缀和库存号组成的复合键,它们组合构成完整的SKU),而不是ID和I我不确定这是否会成为性能问题(当然,我总是可以在这些列上手动创建索引来加快速度)。但这确实意味着我需要脱离Rails约定。
简而言之,我认为就产品上市时间和易于开发而言,Rails可能是一个不错的选择,但是必须使用现有数据内容可能会变成一种痛苦,因为应用程序需要围绕它开发,而不是“传统的”Rails应用程序,这个因素让我对使用Rails产生了重大疑虑。还有一些其他问题(必须设置一个Linux服务器,而且我所居住的区域只有很少的Rails开发人员这样的事实,所以如果我离开公司,我基本上会把他们作为更新/修改的人质) 。我真的不确定最佳路径。
答案 0 :(得分:6)
我会开发应用程序,就好像你没有数据一样。使用ORM并尽可能地使您的数据库成为最佳状态,但当然要记住您需要填充的数据(例如:不要对那些会让您通过记录进行旧数据记录的事情做出疯狂的新约束)。
完成并测试后,编写一个导入脚本,将实际数据提取到新数据库中。
与传统的设计/开发模式没有什么不同......除了您可以半自动化方式进行数据输入。
答案 1 :(得分:1)
不久前我处于相同的情况 - 一个糟糕的PHP应用程序,持有十年的所有公司数据。
我所做的只是创建一个迁移模型,并添加了导入每个资源的方法。
class Migration
def migration_all
self.jobs
end
def self.jobs
...
end
end
关于这一点很酷的是,您可以安排导入哪些订单资源,因为可能会引用另一个订单资源。我还添加了直接修改db模式的方法。如果你必须保留一个现有的主键,一个很好的技巧是创建一个名为'legacy_id'的字段,复制现有的主键,完成后,只需删除'id'字段,重命名'legacy_id'字段到'id',然后在新的'id'字段上添加primary_key约束。
答案 2 :(得分:1)
不要将SKU用作每个产品的唯一密钥 - 使用标准的Rails增量ID。
SKU可能会因为可能被误导等而发生变化,这会使改变其他表中的所有引用成为一场噩梦。将您当前的id放在sku列中,对其进行索引并将其他表中的引用更新为Rails ID。
您可以在控制器中执行Product.find_by_sku(params [:sku]),设置/ products /:sku路线等。我看不到你会得到什么(除了通过使用非生成的id作为数据库主键来解决问题。
答案 3 :(得分:1)
我还建议您通过应用程序的验证运行旧数据,以确保您没有加载一堆不一致和错误。它可以帮助您的应用顺利运行并突出显示现有的数据错误。
不要仅仅因为现有数据已经存在就认为它是有效的。