Questions tagged «physical-design»

1
多租户SQL Server数据库中的复合主键
我正在使用ASP Web API,实体框架和SQL Server / Azure数据库构建多租户应用程序(单个数据库,单个架构)。此应用将由1000-5000个客户使用。所有表都将具有TenantId(Guid / UNIQUEIDENTIFIER)字段。现在,我使用的是ID(Guid)的单字段主键。但是,仅使用Id字段,我就必须检查用户提供的数据是否来自/正确的租户。例如,我有一个SalesOrder包含CustomerId字段的表。每次用户发布/更新销售订单时,我都必须检查是否CustomerId来自同一租户。情况变得更糟,因为每个租户可能都有多个出口。然后我要检查TenantId和OutletId。这确实是维护的噩梦,并且对性能不利。 我正在考虑将一起添加TenantId到主键中Id。并可能也添加OutletId。所以在主键SalesOrder表将是:Id,TenantId,和OutletId。这种方法的缺点是什么?使用复合键会严重损害性能吗?复合键顺序重要吗?我的问题有更好的解决方案吗?

3
从表中获取最后一行的最快方法是什么?
我有一个PostgreSQL表Prices,其中包含以下列: price (十进制) product_id (整数) 也有created_at和updated_at列。 价格会定期更新,我将旧价格保留在表格中。对于给定的产品,表中的最后一个价格是当前价格。 获得特定产品最后价格的最有效方法是: 索引product_id并查询最后一条记录 添加第三列active(布尔值)以标记最新价格,并创建一个复合索引(product_id和active) 或者是其他东西?

1
PostgreSQL如何物理排序磁盘上的新记录(在主键上的集群之后)?
需要知道PostgreSQL如何排序磁盘上的记录。在这种情况下,我想利用docs中所述的索引组合,据我所知,它使用位图来获取匹配的行并根据其物理位置返回它们。该表已通过其主键进行了聚类。 据我了解,PostgreSQL在聚类完成后不会自动继续进行聚类(尽管它确实记得它是根据某个索引进行聚类的)。现在,由于这是主键,所以我想知道物理存储顺序是否符合该顺序(如果为true,我想利用它来进行特定查询)。 总之,PostgreSQL如何排序其新记录,尤其是在集群之后? 非常感谢!

2
为charindex函数分割/存储长字符串的最快方法
我有一个1 TB的数字字符串。给定一个12个字符的数字序列,我想在原始字符串(charindex函数)中获得该序列的开始位置。 我已经使用SQL Server使用1GB字符串和9位子字符串测试了此字符串,并将该字符串存储为varchar(max)。Charindex需要10秒。将1GB的字符串分成900个字节的重叠块,并创建一个表(StartPositionOfChunk,Chunkofstring),该表的二进制排序规则中使用chunkofstring,建立索引所需的时间不到1秒。10GB的后一种方法是10个数字子串,将charindex升至1.5分钟。我想找到一种更快的存储方法。 例 字符串:0123456789-搜索345 charindex('345','0123456789')的子字符串得出4 方法1:现在,我可以将其存储在由一列组成的SQL Server表strtable中colstr并执行: select charindex('345',colstr) from strtable 方法2:或者我可以通过拆分原始字符串来组成表strtable2(pos,colstr1):1; 012 | 2; 123 | 3; 234 aso,然后我们可以进行查询 select pos from strtable2 where colstr1='345' 方法3:我可以通过将原始字符串分成较大的块1; 01234 |来组成表strtable2(pos2,colstr2)。4; 34567 | 7; 6789然后 select pos2+charindex('345',colstr2) from strtable2 where colstr2 like '%345%' 第一种方法最慢。 第二种方法炸毁了数据库的存储容量! 方法3:在二进制排序规则中,将colstr2长度设置为900字节,在此列上创建索引需要1秒的时间来进行1GB字符串和9位数字子字符串的搜索。对于10GB的字符串和10位的子字符串,ist需要90秒。 还有其他想法如何使它更快(也许通过利用包含长整数的数字组成的字符串,....)? SQL Server 2017 …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.