如何直接扫描SQL索引表

发布于 2024-10-01 22:09:15 字数 379 浏览 0 评论 0原文

我有一个 SQL 表,其中的索引包含要调用的线索。大约 30 位用户将致电这些潜在客户。为了确保没有两个用户呼叫同一个线索,系统必须是即时的。

所以我想这样走:

  • 将表设置为正确的索引
  • 扫描表中是否有我可以呼叫的线索(有条件),跟随索引
  • 当我有呼叫时,指示该记录“正在使用”

这里我的问题是: - 我找不到任何方法通过 C# 代码将表设置为索引 - Linq 需要 dataContext(不是即时的)而 ADO 需要 DataSet

我还没有找到任何资源来帮助我解决这个问题。如果您有的话,我们非常欢迎。

抱歉,如果我听起来很无知,我是 SQL 数据库的新手。

预先非常感谢您! 马蒂厄

I have a SQL table with indexes containing leads to call. About 30 users will be calling these leads. To be sure that there is no two users calling the same lead, the system has to be instant.

So I would like to go this way:

  • Set the table to the right index
  • Scan the table for a lead I can call (there are conditions), following the index
  • When I have a call, indicate that the record is "in use"

Here are my issues:
- I can't find any way to set a table to an index by c# code
- Linq requires dataContext (not instant) and ADO requires DataSet

I have not found any resource to help me on that. If you have any, they are more than welcome.

Sorry if I may sound ignorant, I'm new to SQL databases.

Thank you very much in advance!
Mathieu

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

椵侞 2024-10-08 22:09:15

我以前曾在类似的系统上工作过。我们采取的策略是制定一个分发例程,负责将线​​索分发给呼叫中心人员。通常,我们有一个时间限制,即在线索被拉走并交给其他人之前,线索可以在任何一个用户队列中停留多长时间。

这使我们能够做一些相当复杂的事情,例如根据有关潜在客户的详细信息以及呼叫中心人员的工作效率来给予偏好。

我们收到了大量的潜在客户,因此我们的分配例程设置为每分钟运行一次。 SLA 的设置是为了在我们知道后 2 分钟内联系潜在客户。

为了支持这一点,您的潜在客户表应该有一个AssignedUserId,并且可能有一个分配的日期/时间戳。编写一个过程或一些 C# 代码,从该表中获取所有未分配的记录。执行分配例程,将更改保存回表中。此例程可能应该考虑他们当前正在工作的潜在客户数量以及每人可接受的开放潜在客户数量,以便在循环分配中给予优先权。

当用户刷新时,他们将获得线索。您可以在 UI 中控制刷新率。

I've worked on similar systems before. The tact we took was to have a distribution routine that handled passing out the leads to the call center people. Typically we had a time limit on how long the lead was allowed to be in any one users queue before it was yanked away and given to someone else.

This allowed us to do some pretty complicated things like giving preference based on details about the lead as well as productivity of the individual call center person.

We had a very high volume of leads that came in and had our distribution routine set to run once a minute. The SLA was set so that a lead was contacted within 2 minutes of us knowing about them.

To support this, your leads table should have a AssignedUserId and probably a date/time stamp of when it was assigned. Write a proc or some c# code which grabs all the records from that table which aren't assigned. Do the assignment routine, saving the changes back to the table. This routine should probably take into account how many leads they are currently working and the acceptable number of open leads per person in order to give preference in a round robin distribution.

When the user refreshes they will have their leads. You can control the refresh rate in the UI.

梦幻之岛 2024-10-08 22:09:15

我不明白您对“即时”的要求与索引的使用有何关系。通过索引访问表也不是即时的。

为了解决您的问题,我建议在呼叫线索时锁定整个表。这会限制性能,但也会确保同一个线索永远不会被两个用户调用。

示例代码:

Begin Transaction
Lock Table
Search for Lead
Update Lead to indicate that it is in use
Commit Transaction (removes the lock)

可以使用 SELECT * FROM table WITH (HOLDLOCK, TABLOCKX) WHERE 1=0 来锁定 SQL Server 中的表直到事务结束。

免责声明:是的,我知道具有更少锁定的更干净的解决方案是可能的。上述解决方案的优点是它很简单(不用担心正确的事务隔离级别等)并且通常性能足够(如果您记得保持“锁定部分”简短并且没有太多并发访问) 。

I don't see how your requirement of being "instant" relates to the use of an index. Accessing a table by index is not instantaneous either.

To solve your problem, I would suggest to lock the whole table while a lead is being called. This will limit performance, but it will also ensure that the same lead is never called by two users.

Example code:

Begin Transaction
Lock Table
Search for Lead
Update Lead to indicate that it is in use
Commit Transaction (removes the lock)

Locking a table in SQL Server until the end of the transaction can be done by using SELECT * FROM table WITH (HOLDLOCK, TABLOCKX) WHERE 1=0.

Disclaimer: Yes, I'm aware that cleaner solutions with less locking are possible. The advantage of the above solution is that it is simple (no worrying about the correct transaction isolation level etc.) and it is usally performant enough (if you remember to keep the "locked part" short and there is not too much concurrent access).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文