有没有办法在基础数据库方案中设置外键列的名称? [英] Is there a way to set the name of the foreign key column in the underlying database scheme?

问题描述

我有一个客户表和一个CodeValue表. codeValue表包含各种下拉列表".不同类型的代码类别的值:CustomerType，CustomerRegion，CustomerStatus等...

I have a customer table and a codeValue table. The codeValue table contains al kinds of "dropdown" values for different types of code categories: like CustomerType, CustomerRegion, CustomerStatus, etc ...

这些代码类别不是通过LS应用程序管理的，而是仅由后端进程管理的.

These code categories are not managed via the LS app but just by a backend process.

关键是为外键列生成的名称有点怪:Customer_CodeValue，Customer_CodeValue1，Customer_CodeValue2，...

The point is that the names generated for the foreign key columns are a bit weired: Customer_CodeValue, Customer_CodeValue1, Customer_CodeValue2, ...

当然，从独立的LS应用程序的角度来看，我不在乎，因为底层数据库命名是LS的问题，而不是我的问题.但是，在外部进程正在馈送LS db的情况下，这些命名令人困惑.

Of course, from the point of view of a standalone LS app I wouldn't care, because the underlying database naming is the problem of LS, and not mine. But in the case that an external process is feeding the LS db, these namings are confusing.

弄清楚.lsml文件:(

The only way to figure out to which field things are mapping, is by analysing the .lsml file :(

任何想法??

thx

 

推荐答案

Hiya Paul，

Hiya Paul,

我了解您正在谈论使用具有多个列的表，这些表是同一相关表的FK.

I understand that you are talking about having a table with multiple colums that are FKs to the same related table.

LS将单个FK字段名称重命名为FK表实体的复数名称.当同一张表有多个FK时，LS会将后缀号添加到多个FK实体.这是非常模棱两可和有问题的.

LS renames individual FK field names to the plural name of the FK table Entity.  When there are multiple FKs for the same table, LS will add a suffix number to the plural FK Entity.  This is extremely ambiguous and problematic.

根据我的观察，父表中FK列的放置顺序决定了后缀的编号.

From what I've observed, the order of the placement of the FK column in the parent table is what determines the suffix numbering.

我将始终进入每个模块化LS应用程序，并重新命名该字段以明确显示该目的.

I will always go into each modular LS app and rename the field to be clear on the purpose.

换句话说，我将在Enity Designer中手动将CodeValues，CodeVaules1，CodeValues2等重命名为CustomerType，CustomerRegion，CustomerStatus等.

In other words, I will manually rename CodeValues, CodeVaules1, CodeValues2, etc. to CustomerType, CustomerRegion, CustomerStatus, etc in the Enity Designer.

与其让LS使用含糊的数字，不如让列名是FK复数实体，后跟父表FK字段名.

Instead of having LS use ambigous numbers, it would be better to have column name that is the FK plural Entity followed by the parent table FK field name.

这种方法类似于嵌套查询将为Screen Collection参数创建局部变量的方式.

This approach is similar to the way that nested queries will create local variables for Screen Collection paramenters.

这是AR分配表的屏幕快照，该表将付款和费用与AR交易和AR分配表之间的一对多关系进行匹配.如果商家采用的是累计方式，则费用会在开具发票时过帐. 如果业务是以现金为基础的，则在收到付款之前，收入不会记入GL.大多数公司仍希望查看其开放式AR的详细信息，因为它与尚未收到的付款有关.分配通常是 自动收取最旧的费用，但是当AR检查指定如何应用时可以被覆盖.

Here's a screenshot of an AR Allocation table that matches payments and charges with a 1 to Many relationship between the AR Transaction and the AR Allocation table.  If the business is on an accural method the charges are posted when invoiced.  If the business runs on a cash basis, the revenue is not posted to the GL until payment is received.  Most companies still want to see the details of their open AR as it related to payments that have not been received.  The allocation is normally automatic to the oldest charges but can be overridden when an AR check specifies how it is to be applied.  

在这里您看到，由于两个FK都指向同一个ARTrans表，因此LS创建了后缀"1".第二个ARTransAllocations复数名称.

Here you see that since both FKs point to the same ARTrans table, LS has created the suffix of "1" for the second ARTransAllocations plural name.

ARTransAllocation表具有FK字段，这些字段当然是唯一的，并指定每个字段的用途:

The ARTransAllocation table has FK fields that, of course, are unique and specify the purpose of each field:

所以. . .在LS中，我只需手动为每个FK添加正确的后缀，以便每个人都知道哪个FK用于收费，哪个FK用于付款.

So . . . in LS, I simply manually add a the correct suffix to each FK so that everyone knows which FK is for Charges and which FK is for Payments.

在分配"屏幕中，我仅具有2个组"部分，它们具有单独的屏幕集合，用于将费用分配到付款"或将付款分配"到费用".屏幕逻辑显示适当的组.非常简单而强大. 如果您从LightSwitch的角度进行设计，这是LS v1可以使代码可重用的一个很好的例子.

In the Allocation screen, I simply have 2 Group sections with separate Screen Collections for Charge distribution to a Payment or Payment distribution to a Charge.  The Screen logic displays the appropriate group.  Very easy and powerful.  This is a good example of what LS v1 can do to make code reusable - if you approach design from a LightSwitch perspective.

在Paul的情况下，指向同一codeValue表的多个FK表示LS(与其他ERP/LOB平台一样)可以重用通用数据基础结构并支持极其灵活的软件设计的另一种方式.满怀希望，有了LS V2，我们将 在运行时具有即时生成和/或修改屏幕的更多功能.

In Paul's case, the multiple FKs to the same codeValue table represent another way LS (like other ERP/LOB platforms) can reuse a common data infrastructure and support software design that is extremely flexible.   Hopefullly, with LS V2 we will have more capability to generate and/or modify Screens on the fly at runtime.

这篇关于有没有办法在基础数据库方案中设置外键列的名称?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！