关于在 Microsoft 环境中创建内部营销活动数据库的建议？
我想创建一个内部解决方案来存储营销细分、列表、活动和通信数据。现在没有什么是集中/标准化的。数据位于各种 SQL 服务器、Access 数据库和 Excel 电子表格中。在报告/跟踪方面确实很痛苦。
我处于 Microsoft SQL Server 环境中，可以访问：
- Microsoft Access
- Microsoft SQL Server Management Studio
- Microsoft Business Intelligence Development Studio
在我的环境中，安全性和合规性受到相当严格的限制。购买第三方软件包似乎不是一个选择。我可能有可能创建一个 SQL Server 沙箱环境供我使用。
我很好奇你会推荐什么建议以及为什么。我需要考虑所有方面，包括现有的数据检索/解析（有些是持续的）、数据导入到新的营销数据集市以及报告。可能需要某种 GUI，因为当前没有用于跟踪/分类大量数据的 GUI。另一位人员可能需要帮助进行定期导入，以帮助分散工作量。
谢谢。
I'd like to create an in-house solution to store marketing segment, list, campaign, and communication data. Right now nothing is centralized/standardized. Data is located on a variety of SQL servers, Access databases, and Excel spreadsheets. It's been a real pain when it comes to reporting/tracking.
I'm in a Microsoft SQL Server environment and have access to:
- Microsoft Access
- Microsoft SQL Server Management Studio
- Microsoft Business Intelligence Development Studio
Security and compliance is pretty restrictive in my environment. Purchasing a third party software package doesn't appear to be an option. I may have the possibility of having a SQL server sandbox environment created for my use.
I'm curious what suggestions you would recommend and why. I need to think about all aspects including existing data retrieval/parsing (some on a continuing basis), data import into the new marketing datamart, and reporting. Some kind of GUI may be required as there isn't currently one for tracking/categorizing much of the data. One other individual may need access to help with regular imports to help spread workload.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的要求不完整：
这是你的问题：“我很好奇你会推荐什么建议以及为什么”
这就是答案。
谁会使用这个？到底是谁？给他们每一个人打电话，谈谈他们的工作。
商业价值是什么？ “存储营销细分、列表、活动和通信数据的解决方案”是一个坏主意。没有人想要一个“解决方案”——他们想要完成自己的工作。很少有人会遇到需要“解决方案”的“问题”。他们已经完全能够胜任自己的工作了。你能做的最好的事情就是让他们更有效率。他们关心个人效率吗？我对此表示怀疑。
谁有问题？他们有什么问题？
想想“培根鸡蛋早餐”。鸡下了一个蛋然后走开了。然而，猪却完全专注于培根。
找到猪和鸡。您的数据不会识别您的参与者和您的业务问题。找到有问题的人。找出问题有多大、成本有多大。绝对确定，您已经发现了导致某人付出真正金钱的真正问题。安慰那些损失最多钱的人，并确保他们希望自己的问题得到解决。他们是猪——他们可以全身心投入。
最终，您将希望构建一个中央 SQL/Server 数据库并摆脱 Excel 电子表格和 MS-Access 数据库。您可能想要一个 MS-Access 前端，它提供使用 SQL/Server 的优秀应用程序。
如果您实际上在谈论数据仓库，那么接下来您必须阅读 Ralph Kimball 的书籍。 [顺便说一句，数据仓库是否相关还不清楚。由于没有问题需要解决，也没有用户遇到问题，数据仓库对我来说就像 Web 服务框架或新 Bentley 一样糟糕（Black 和 Silver，谢谢。）
如果您想构建一个数据仓库，您的“现有数据检索/解析”和“数据导入新营销数据集市”将称为ETL。
你的“和报告”将从“哦，顺便说一句”转变为你正在做的事情的最重要的核心特征。
你的“某种 GUI”将会消失。数据仓库并不是 GUI 的东西。报告是尽可能接近的。也许您必须创建一些主数据管理工具，但即使如此，这些也只是规则而不是交互。
“另一个人可能需要访问权限”真的吗？最终用户是什么？肝脏切碎？他们也需要查询访问权限，否则他们将看不到您的任何数据。
Your requirements are incomplete:
Here's your question: "I'm curious what suggestions you would recommend and why"
Here's the answer.
Who will use this? Exactly who? Call every single one of them and talk to them about what they do.
What is the business value? "solution to store marketing segment, list, campaign, and communication data" is a bad idea. No one wants a "solution" -- they want to get their jobs done. Few people have "problems" that need "solutions". They are already perfectly able to do their job. The best you can do is make them more efficient. Do they care about their personal efficiency? I doubt it.
Who has the problem? What problem do they have?
Think of a "Bacon and Eggs Breakfast". The chicken lays an egg and walks away. The pig, however, is totally committed to the bacon.
Find the pigs and chickens. Your data is not going to identify your actors and your business problem. Find the people who have the problem. Find out how big and costly the problem is. Be absolutely sure, you've found the real problem that is costing someone real money. Cozy up to the person who's losing the most money and make sure they want their problem solved. They are the pig -- they can be totally committed.
Eventually, you'll want to build one central SQL/Server database and get rid of Excel Spreadsheets and MS-Access databases. You might want to have an MS-Access front-end which provides nice applications that use SQL/Server.
If you are actually talking about a data warehouse, then you must next read books by Ralph Kimball. [It's not clear, BTW, that a data warehouse is even relevant. With no problem to solve and no user who has the problem, a data warehouse is just as bad an idea as a web services framework or a new Bentley for me (Black and Silver, thank you.)
If you want to build a data warehouse, your "existing data retrieval/parsing" and "data import into the new marketing datamart" will called ETL.
Your "and reporting" will be moved from an "oh, by the way" to the central most important feature of whatever it is you're doing.
Your "Some kind of GUI" will go away. Data warehousing is not much of a GUI thing. Reporting is as close as you get. Maybe you'll have to create some Master Data Management tools, but even then, those are more rules than interactions.
"One other individual may need access" Really? The end users are what? Chopped liver? They need query access, too, or they won't see any of your data.
您指出购买第三方软件不是一种选择，但是，您应该考虑到购买实际上可能比内部开发工作更便宜，并且可能会更快地让您进入工作系统，而需要较少的内部技能必需的。
You indicate that a purchase of third party software is not an option, however, you should consider that the purchase may in fact be cheaper than the in house development effort, and may bring you to a working system much faster, with less in house skills required.