我（也）写了一个基于群发邮件网络的应用程序。这是一个音乐会组织者。我邀请乐器演奏者参加每个音乐会来自SQL DB，我需要跟踪这些人的情况（主要是手动喂食:)然后我想向他们发送排练时间表和我转移到他们的金额。
所以，假设我每年举办15场音乐会，每场演唱会邀请100-200名演员，我想要80 /演唱会。
我的SQL设计将是：
联系方式DB |音乐会项目DB |跟踪数据库
您是否认为几年后跟踪操作太大而无法操作，或者我可以通过网络管理多少记录而没有明显增加的加载时间。或者那里有更好的主意吗？
任何有想法的人请轰炸我:)））谢谢
答案 0 :(得分：1)
以每年5000的速度，即使您在手机上托管数据库，它也会快速吸烟，所以不要失去任何睡眠。 即使你每年有50万的东西（这么多100倍），你最终会在5年内拥有一个拥有250万条记录的数据库，这仍然不是一个相当便宜的服务器可以处理的巨大数量即便在今天，更不用说5年了。
所以，无论你想要什么，按照你的速度它会很好，但如果你想发布一个详细的数据库模型，我相信有人会给你反馈。只是停止思考很多关于优化和做坏事的事情，你会感觉更好。