Algorithm 数据库记录到网格的转换

当我们需要将数据库记录转换为网格时，我们遇到了一个问题

我的意思是：

u1 | q1 | a12
u1 | q2 | a22
...
u1 | qN | a1N
u2 | q1 | a21
u2 | q2 | a22
...
u2 | qK | a2K
u3 | q1 | a31
u3 | q2 | a32
...
u3 | qL | a3L
...
uM | q1 | aM1
uM | q2 | aM2
...
uM | qR | aMR

M ~ 1000
N,K,L,R ~ 50

===============>

 #  q1   q2   ...  qN   qK   qL   qR
u1  a11  a12  ...  a1N  -    -    -
u2  a21  a22  ...  -    a2K  -    -
u3  a31  a32  ...  -    -    a3L  -
...
uM  aM1  aM2  ...  -    -    -    aMR

因此，顶部的矩阵反映了数据库中的记录集， 由u（用户）订购，q（问题）订购。 每个用户可能有不同数量的问题答案

底部矩阵是我们需要转换的，它是某种网格。 正如您所见，一些用户可能有或可能没有一些问题/答案对，这将有一些差距。以及这些差距的“结构” 可以非常（因此不完全是前两个问题/答案将首先获取）

虽然我们已经有了一些工作算法，但由于它遍历了一个数据集两次，所以很难闻

也许有人知道如何最有效地进行这种转换

p、 美国。 不幸的是，我们不能改变问题的条件，这意味着 顶部的矩阵必须是这种形状，并且问题不能通过对db的额外调用来解决。 用例是一个报告环境，它只允许进行一次查询，然后将数据后处理到我们需要的内容中。

类似的情况

import os
from sets import Set

data = r"""u1 | q1 | a12
u1 | q2 | a22
u1 | qN | a1N
u2 | q1 | a21
u2 | q2 | a22
u2 | qK | a2K
u3 | q1 | a31
u3 | q2 | a32
u3 | qL | a3L
uM | q1 | aM1
uM | q2 | aM2
uM | qR | aMR"""

s = data.split("\n")

users = {}
questions = Set()

for l in s:
    (u, q, a) = l.split("|")
    questions.add(q)
    if users.has_key(u):
        users[u][q] = a
    else:
        users[u] = {q:a}

# print header 
str = "%5s " % " "
for q in questions:
    str += "%5s" % q
print str

# print the table
for u in users:
    str = ""
    str += "%5s " % u
    for q in questions:
        if users[u].has_key(q):
            str += "%5s" % users[u][q]
        else:
            str += "  -  "
    print str

输出如下所示：

>>> 
        q1   qR   q2   qK   qN   qL 
  u1    a12  -    a22  -    a1N  -  
  u2    a21  -    a22  a2K  -    -  
  uM    aM1  aMR  aM2  -    -    -  
  u3    a31  -    a32  -    -    a3L

---

因此，我希望使用一种常见的数据结构（如：数组、哈希映射等）得到一个答案。我们将屏住呼吸。你有网格数据结构吗？你只是在寻找一种算法来读取数据库并生成像

grid[u1][q1]=a11

这样的调用，还是你也在要求网格数据结构？实际上，输出数据结构必须是一个数组。因为我们将在lib旁边创建一个pas，lib将从中生成一个Excel文件。但是我们正在寻找的算法不应该做嵌套循环（如果可能的话），我不认为它是有效的。在每一次迭代中都有另一个迭代：has_key然后在最后再次进行相同的迭代，不同的是它变成了“用户”，在每一次迭代中，它不是只遍历has_key，而是在每个问题迭代中进行。我不擅长估计运行时间，但两个循环依次嵌套似乎效率不高。基本上，我们有非常相同的，也许有点优化