如何有效地将复杂MySQL数据库的视图用于CRUD?

如何有效地将复杂MySQL数据库的视图用于CRUD?,mysql,ms-access,stored-procedures,view,crud,Mysql,Ms Access,Stored Procedures,View,Crud,我正在构建一个MySQL数据库,最终目标是在MicrosoftAccess中创建一个GUI CRUD前端。附件中的图片是该数据库联系人部分的布局。[] 理想情况下,此屏幕截图中的所有表(不包括付款)都将填充在一个访问表单中,但我很难找到实现这一点的方法。最明显的答案(以我有限的SQL知识)是创建一个连接所有这些表的海量视图,然后让Access窗体调用一个存储过程(一个海量SP,或者每个字段一个?这一点不清楚)来C/R/U/D视图 我测试了使用以下几个表(一对多关系和一对多)创建视图: 我走对了吗

我正在构建一个MySQL数据库,最终目标是在MicrosoftAccess中创建一个GUI CRUD前端。附件中的图片是该数据库联系人部分的布局。[]

理想情况下,此屏幕截图中的所有表(不包括付款)都将填充在一个访问表单中,但我很难找到实现这一点的方法。最明显的答案(以我有限的SQL知识)是创建一个连接所有这些表的海量视图,然后让Access窗体调用一个存储过程(一个海量SP,或者每个字段一个?这一点不清楚)来C/R/U/D视图

我测试了使用以下几个表(一对多关系和一对多)创建视图:


我走对了吗?这样的观点似乎很快就会变得不舒服。

无论是桌面、网络还是任何平台

通过将基于关系的零件拼凑在一起,可以对关系数据进行建模、显示和编辑

但是,实际上每个部分都直接基于一个表。您不需要创建视图服务器端来将所有数据连接在一起。而且您也不使用SQL

如果您有一个客户和30张发票,那么如果您加入表,那么该客户将出现30次。您不可能编辑一个数据行这样的混乱

这是相关的表格:

因此,在access的情况下,您将构建一个表单来编辑主客户。这样的表单允许您一次编辑一个客户。构建一个表单——让它很好地工作

同样,上面是基于一个链接表

现在,要显示一个客户的发票吗?好的,现在构建一个新表单(多项目表单)。您可以将此表单建立在发票表的基础上

一旦你建立了这两种形式?好的,在设计模式下打开主客户表单,现在只需从中堂窗格拖放发票表单

所以,你会看到这样一个屏幕:

您可以看到主表单包含客户名称、地址等内容

另一个表单(子表单)显示了您为这一客户提供的发票列表

访问的美妙之处在于它将为您连接主窗体和子窗体,并且不需要代码。因此,您导航到的每个主要客户记录现在都将在该子表单中显示与子记录相关的记录。您可以通过在子窗体控件中设置链接主设置和子设置来执行此操作:

现在,当然每个发票都有一个“主”发票部分。(日期、客户,可能是账单地址)。对于每个发票,您将有一个子发票明细表。(一张发票中每件物品的数量、项目、价格金额等)。因此,再次对该发票表单和子表单“发票明细”重复上述简单概念

因此,在上面我单击发票时,我们只需打开一个主发票表单到一个发票记录,子发票详细信息再次显示为子表单。像这样:

那么,这是桌面开发,还是web开发

您可以创建一个用户界面,该界面基于将零件拖放到表单中,每个表单都基于一个表

因此,作为一般规则显示记录的每个部分将基于单个表。因此,对于此类数据编辑,您将永远不会使用连接在一起的视图或数据进行编辑

使用Access,您也不会使用任何sql

用于编辑数据的每个位和部分将直接基于access中的单个链接表,而不是某些视图

因此,您不需要视图,甚至构建的每个部分都不需要sql

因此,编辑关系数据的能力将取决于您如何拼凑每个位和部分,但这些部分中的每一部分都不会基于某些sql查询,事实上也不会基于视图。您使用的每个零件都将直接基于一个链接表和一个单独的表

此处使用的每个部件一次只编辑一条记录。把最后一句读10遍,确保你掌握了这个简单的规则

所以,你当然可以发挥创造力。下面是一个示例表单,它同时显示了3个表。在这个例子中,我们有一个活动,然后是一个人和他们的捐款。我们需要把捐款分成不同的账户。有人可能会给50美元,但10美元用于葬礼,另外40美元可能用于学校

顶部是捐赠活动(一个记录)。左侧是一张表格,显示了为活动捐款的人及其金额。在右边,我们展示了我们在左边选择的单个捐赠的账户。每次捐款都可以分成多个账户

这是一个常见的“经典”会计类型屏幕,您可以在其中输入给定金额,但将其拆分并应用到多个帐户中

同样,上面的访问表单不是基于视图,甚至不是基于sql查询,但是我们放入表单中的每个部分都基于一个链接表

因此,您可以将位和部分的切片和切分放入表单中,从而允许并允许您编辑相关数据,但每个部分仅基于相关数据模型中的一个表

正是“如何”将这些零碎的部分拼凑在一起,才有了编辑相关数据的魔力。因此,您的这一过程和想法与构建连接相关数据的视图几乎没有关系。在上面的所有示例中,我没有编写任何sql或创建任何视图,每个部分都只是直接基于链接表,甚至没有一些sql。因此,您的相关数据模型是一个“指南”,它将为您提供有关构建用户界面时下一步将使用哪个表和部件的信息

通常,我
CREATE 
ALGORITHM = UNDEFINED 
DEFINER = lauren3@% 
SQL SECURITY DEFINER
VIEW peopleformview AS
SELECT 
    p.PersonID AS personid,
    p.Title AS title,
    p.FirstName AS firstname,
    p.LastName AS lastname,
    p.Role AS role,
    p.DOB AS dob,
    p.PassportNum AS passportnum,
    p.Alumni AS alumni,
    p.Degree AS degree,
    p.Nickname AS nickname,
    p.Email AS email,
    p.PermissiontoEmail AS permissiontoemail,
    ar.agent AS agent,
    a.AddressID AS AddressID,
    a.Address1 AS Address1,
    a.Address2 AS Address2,
    a.City AS City,
    a.State_Province AS State_Province,
    a.PostCode AS PostCode,
    a.Country AS Country
FROM
    (((people p
    LEFT JOIN agentref ar ON ((p.agentref_agentid = ar.agentid)))
    LEFT JOIN people_has_addresses pha ON ((pha.people_PersonID = p.PersonID)))
    LEFT JOIN addresses a ON ((pha.addresses_AddressID = a.AddressID)))