我正在与一个需要生成数百万字母数字代码的客户合作,这些代码用于杂志刮刮卡,瓶装奖品等.它们必须足够短以便在帽子上打印,他们希望确保不包括像1和I,0和O等模糊字符,并且必须明确存储它们以备将来使用 - 我们可以'只有一个算法可以在某人试图兑换一个时确定"有效性".最后,他们希望确保代码随机分布在一个大的"代码空间"内,这样人们就不能通过遍历字母表来猜测其他代码.
有没有指向合理有效的算法来生成这些类型的代码集？我在信封的背面刮了几下,但这个问题闻起来像是一个不知情的陷阱.
我和几位同事面临着一个具有严重性能影响的架构决策:我们的产品包括一个UI驱动的架构构建器,允许非程序员为Web应用程序构建自己的数据类型.目前,它在幕后构建了正确的规范化模式,并包含一些复杂的逻辑来改变模式,并在管理员对数据类型进行更改时自动迁移旧数据.
规范化的模式在过去已经遇到了性能瓶颈,并且已经安排了一次重大的重构.其中一组开发人员希望将数据类型的每个属性存储在一个单独的表中,以便对数据类型的更改永远不需要更改模式.(单个属性可以转换为1:n关系,例如,只需更改应用程序逻辑.)
因为早期的基准测试表明这将导致巨大的性能损失,他们在应用程序代码中构建了一个缓存层,用于维护每种数据类型的非规范化版本.虽然它确实加快了查询速度,但我对应用程序层将要承担的复杂性持怀疑态度,但我希望得到反馈 - 我是否感到悲观？是否已成功部署此类解决方案？我应该坚持使用枪支,还是将复杂性从"架构修改工具"转移到"架构镜像工具"是一件好事？