给我一个提示我的项目 [英] Give me a hint to my project

问题描述

我想将包括医生在内的患者的信息(Id，姓名，年龄，电话)从Doctor1转移到Doctor2
每个医生也都有一个ID.

要进一步说明:
-我设计了一个gridview来显示患者信息.
-我已添加到此gridview列包含复选框中，以确定要转移给其他医生的那些患者.
-最后有清单选择要接受患者的医生姓名，然后单击按钮进行转移.

任何人都可以帮助我如何以编程方式解决此问题?

我正在使用c#

谢谢

I want to transfer the information of patients included (Id,Name,Age,tel) from doctor1 to doctor2
each doctor have an Id also.

To more clarify:
-I designed a gridview to show the information of patients.
-I added to this gridview colum contain checkbox to determine those patients I will transfer to other doctor.
-Finally there is checklist to choose the name of the doctor that will accept the patients and button to do the transfer.

Any one can help me how can I programmatically solving this problem?

I am using c#

Thank you

推荐答案

您显然需要一些表格来关联患者和医生

Doctor_Patient
INT Doctor_ID
INT Patient_ID

除非只有一个与该患者相关的文档，否则在这种情况下，请考虑从医生表中向该患者表添加外键

患者
ID，姓名，年龄，电话，Doctor_ID

当您希望其他医生与患者联系时

更新Doctor_Patient
SET Doctor_ID = New_Doc_ID
在哪里Patient_ID = ???

或

更新患者
SET Doctor_ID = NewDoc_ID
在哪里Patient_ID = ???

显然，还需要进行更多的制衡工作，但这是实现此目的的必要过程.

You obviously need some table to associate the patients and doctors

Doctor_Patient
INT Doctor_ID
INT Patient_ID

Unless there can be only one doc associated with the patient, which in that case consider adding a foreign key to patient table from the doctors table

Patient
ID, name, age, tel, Doctor_ID

When you want another doctor to be associated with the patient

UPDATE Doctor_Patient
SET Doctor_ID = New_Doc_ID
WHERE Patient_ID = ???

Or

UPDATE Patient
SET Doctor_ID = NewDoc_ID
WHERE Patient_ID = ???

Obviously there are more checks and balances that need to be done, but this is the essential process for it

派对对派对来说是一种抽象"，而不是您昨晚发泄的派对，但希望有几方出席.

一个人是一个聚会，一个组织也是.以开发人员的身份，我可以说是一名开发人员，当我生病并去看医生时，我可以担当患者的角色.当一位医生不再担任我的医生时，他作为我的医生的角色就结束了，但这并不能改变他一直是我的医生的事实-如果以前的病例出现并发症，这可能证明是阳imp的信息.当我更换医生时，会有一个新人担任我的医生.

这与我概述的设计类似，但更全面:
类似模型的图片 [用于关系开发的通用数据模型 [
在医疗系统中，我作为患者的角色将成为我与医疗机构之间关系的一部分，而医务人员则以其在处理案件中的各种角色进入和离开该关系.如果我在我们的医疗机构当医生，有时我也可以担当病人的角色-但我不应该担当我自己的医生的角色.

处理诸如医生和患者之类的各方之间的交互的通用非常简化的结构，但希望足以让我感到不安.这是Len Silverston提出的模型的非常简化的子集.

A party is an "abstraction" for partys, not the one you vent to last night, but hopefully several parties where present.

A person is a party, and so is an organization. In my capacity as a developer I could be said to have a role as a developer, and when I get sick and visit the doctor I have a role as a patient. When one doctor stops being my doctor, his role as my doctor ends, but that does not alter the fact that he has been my doctor - something that may prove to be information of impotance should complications arise from previous cases. As I change doctors a new person gets the role as my doctor.

Here is something similar, and more comprehensive, to the design I''m outlining:
Picture of a similar model[^]

A Universal Data Model For Relationship Development[^]

In a "real" design we could have entities for PartyType, Party, RelationShipType, RelationShipRoleAssignment, RelationShip ,ContactMechanismType, ContactMechanism, CaseType, Case, and many more. As a person I would have several contactmechanisms assigned to me, and as this information usually changes over time, they too should have FromTime/ThroughTime fields.

In a medical system I would be part of a relationship between the medical facility and me in my role as patient, and medical personel enters and leaves that relationship in their various roles working on cases. If I worked as a doctor at our medical facility, I could sometimes have the role as patient too - but I should not be able to have the role as my own doctor.

General very simplified structure for dealing with interactions between parties, like for instance doctors and patients - but hopefully enough to get my drift. It''s a very simplified subset of the model proposed by Len Silverston.

CREATE SCHEMA [Party]
GO

CREATE SCHEMA [Case]
GO


/* What kind of party? a formal party like a person or an organization, or an informal party like a group or department? */
CREATE TABLE [Party].[PartyType]
(
  [Id] bigint NOT NULL,
  [Name] nvarchar(255) NOT NULL,
  [Extends] bigint,
  [Abstract] bit NOT NULL,
  [Description] nvarchar(2028),

  CONSTRAINT PK_PartyType PRIMARY KEY([Id]),
  CONSTRAINT FK_PartyType_Extends_To_PartyType_Id FOREIGN KEY([Extends]) REFERENCES [Party].[PartyType]([Id]),
  CONSTRAINT UNQ_PartyType_Name UNIQUE(Name)
)
GO

CREATE TABLE [Party].[Party]
(
  [Id] bigint IDENTITY NOT NULL,
  [Type] bigint NOT NULL,

  CONSTRAINT PK_Party PRIMARY KEY(Id),
  CONSTRAINT FK_Party_Type_To_PartyType_Id FOREIGN KEY([Type]) REFERENCES [Party].[PartyType]([Id])
)
GO

CREATE TABLE [Party].[Organization]
(
  [Id] bigint NOT NULL,

  CONSTRAINT PK_Organization PRIMARY KEY(Id),
  CONSTRAINT FK_Organization_Id_To_Party_Id FOREIGN KEY([Id]) REFERENCES [Party].[Party]([Id])
)
GO

CREATE TABLE [Party].[Person]
(
  [Id] bigint NOT NULL,

  CONSTRAINT PK_Person PRIMARY KEY(Id),
  CONSTRAINT FK_Person_Id_To_Party_Id FOREIGN KEY([Id]) REFERENCES [Party].[Party]([Id])
)
GO

CREATE TABLE [Party].[Unit]
(
  [Id] bigint NOT NULL,

  CONSTRAINT PK_Unit PRIMARY KEY(Id),
  CONSTRAINT FK_Unit_Id_To_Party_Id FOREIGN KEY([Id]) REFERENCES [Party].[Party]([Id])
)
GO

/* A party may play any number of roles - like doctor or patient - at any time */
CREATE TABLE [Party].[PartyRoleType]
(
  [Id] bigint NOT NULL,
  [Name] nvarchar(255) NOT NULL,
  [Extends] bigint,
  [Abstract] bit NOT NULL,
  [Description] nvarchar(2028),
  [ValidForPartyType] bigint NOT NULL DEFAULT 1,

  CONSTRAINT PK_PartyRoleType PRIMARY KEY([Id]),
  CONSTRAINT FK_PartyRoleType_Extends_To_PartyRoleType_Id FOREIGN KEY([Extends]) REFERENCES [Party].[PartyRoleType]([Id]),
  CONSTRAINT FK_PartyRoleType_ValidForPartyType_To_PartyType_Id FOREIGN KEY([ValidForPartyType]) REFERENCES [Party].[PartyType]([Id]),
  CONSTRAINT UNQ_PartyRoleType_Name UNIQUE(Name)
)
GO

/* For a period of time party plays a role as patient, doctor, etc. */
CREATE TABLE [Party].[PartyRole]
(
  [Id] bigint IDENTITY NOT NULL,
  [Type] bigint NOT NULL,
  [Party] bigint NOT NULL,
  [FromTime] datetime2 NOT NULL,
  [ThroughTime] datetime2,

  CONSTRAINT PK_PartyRole PRIMARY KEY(Id),
  CONSTRAINT FK_PartyRole_Type_To_PartyRoleType_Id FOREIGN KEY([Type]) REFERENCES [Party].[PartyRoleType]([Id]),
  CONSTRAINT FK_PartyRole_Party_To_Party_Id FOREIGN KEY([Party]) REFERENCES [Party].[Party]([Id])
)
GO


CREATE TABLE [Case].[CaseType]
(
  [Id] bigint NOT NULL,
  [Name] nvarchar(255) NOT NULL,
  [Extends] bigint,
  [Abstract] bit NOT NULL,
  [Description] nvarchar(2028),

  CONSTRAINT PK_CaseType PRIMARY KEY([Id]),
  CONSTRAINT FK_CaseType_Extends_To_CaseType_Id FOREIGN KEY([Extends]) REFERENCES [Case].[CaseType]([Id]),
  CONSTRAINT UNQ_CaseType_Name UNIQUE(Name)
)
GO


CREATE TABLE [Case].[Case]
(
  [Id] bigint IDENTITY NOT NULL,
  [Type] bigint NOT NULL,

  CONSTRAINT PK_Case PRIMARY KEY(Id),
  CONSTRAINT FK_Case_Type_To_CaseType_Id FOREIGN KEY([Type]) REFERENCES [Case].[CaseType]([Id])
)
GO

/* "extends" [Party].[PartyRole] to allow a party to play a role in a case */
CREATE TABLE [Party].[PartyToCaseRole]
(
  [Id] bigint NOT NULL,
  [Case] bigint NOT NULL,
  
  CONSTRAINT PK_PartyToCaseRole PRIMARY KEY(Id),
  CONSTRAINT FK_PartyToCaseRole_To_PartyRole_Id FOREIGN KEY([Id]) REFERENCES [Party].[PartyRole]([Id])
  CONSTRAINT FK_PartyToCaseRole_To_Case_Id FOREIGN KEY([Id]) REFERENCES [Case].[Case]([Id])
)
GO

上面的内容已经相当简化，但我仍然希望它能为您指明正确的方向.有关名称，地址，联系机制等的信息本质上是暂时的，应将其分解到单独的表中，以便您跟踪更改-请勿覆盖它们！！

当医生不再担任医生时，您可以设置通过时间"，当医生开始成为医生时，则可以设置从时间".

在设计表时，请记住一个好主意，即您最终可能希望将它们映射到db之外的某个对象-也许是c#.

以下内容概述了可以构成适当结构基础的内容:

The above is quite simplified, but I still hope it will point you in the right direction. Information about names, adresses, contact mechanisms and so on are temporal in nature and should be factored into separate tables to allow you to track changes - NOT OVERWRITE THEM!!

When a doctor stops having a role as a doctor you set the ThroughTime, when a doctor starts being a doctor you set the FromTime.

While designing the tables, it''s a good idea to keep in mind that you may eventually wish to map them to something outside the db - perhaps c#.

The follwing outlines something that could form the basis for a suitable structure:

 public abstract class Identified
 {
  public long Id {get;set;}
 } 

 public abstract class Named : Identified
 {
  public string Name { get; set; }
 }

 public abstract class abstract Type : Named
 {
  public long? Extends {get;set;} 
  public bool Abstract {get;set;}
  public string Description {get;set;}
 }

 class PartyType : Type
 {
 }

 public abstract class Party : Identified
 {
  public PartyType {get;set;}  
  
  List<partyrole> Roles {get;}

 }

 public abstract class FormalParty : Party
 {
 }

 public abstract class InformalParty : Party
 {
 }

 public abstract class Person : FormalParty 
 {
 }
 
 public abstract class Oragnization : FormalParty
 {
 }

 public class Unit : InformalParty
 {
 }

 
 public class PartyRoleType : Type
 {
 }

 public class PartyRole : Identified
 {
  public PartyRoleType {get;set;}
  public Party Party {get;set;}
  public DateTime FromTime {get;set;}
  public DateTime ThroughTime {get;set;}
 }
 

 public class CaseType : Type
 {
 }

 public class Case : Identified
 {
  CaseType CaseType {get;set;} 
 }

 
 public class PartyCaseRole : PartyRole
 {
  Case Case {get;set;}
 }

</partyrole>

我希望可能的C#实现大纲有助于阐明一些数据库设计.

显然，这与真实"系统的实际设计并不相近，甚至无法满足我在顶部给出的简短描述-但我希望它能说明一些真实世界"的问题" "以及如何设计系统以应对它们-特别是大多数事物本质上都是暂时的-需要FromTime/ThroughTime功能.

如果您按照这种设计的含义进行工作，最终将得到一个数据库结构，该结构最初看起来会相当复杂，甚至非常:).好处是，由于您的结构能够通过简单的机制处理实际场景，因此通常使用起来非常容易.

问候
Espen Harlinn

I hope the outline for a possible c# implmentation helps to clarify some of the database design.

Obviously this doesn''t come close to an actual design for a "real" system, it doesn''t even satisfy the brief desciption i gave at the top - but I hope it serves to illustrate some "real-world" "problems" and how you may design you system to cope with them - specifically that most things are temporal in nature - needs FromTime/ThroughTime functionality.

If you work your way through the implications of this design, you''ll end up with a database structure that initially will seem quite, even very :), complicated. The good thing is that it will usually be quite easy to work with, as you have a structure that is capable of dealing with real scenarios through simple mechanisms.

Regards
Espen Harlinn

< pre lang ="sql"> UPDATE Patient
SET Doctor_ID = NewDoc_ID
在哪里Patient_ID = ???</pre>

谢谢

但我有疑问

您是说要标记新医生的身份证吗?

但在我的项目中没有特定的ID

换句话说，用户无法在每次传输中访问要放置新ID的代码.

怎么可以这样说:当用户选择docor表格核对表的名称并单击按钮转移"时，我通过复选框选择的有关患者的全部信息

我希望了解我

谢谢

<pre lang="sql">UPDATE Patient
SET Doctor_ID = NewDoc_ID
WHERE Patient_ID = ???</pre>

Thank you

but I have qustion

you means in qustion mark the Id of new doctor right?

but in my project there is no specifc Id

In other word, the user can not access the code in every transfer that want to do to put the new Id

How can programmly say : "When the user choose the name of the docor form checklist and click the button "transfer" the whole information about the patients that I selected by check box

I hope that understand me

thank you

这篇关于给我一个提示我的项目的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！