关系数据库表

发布于 2024-08-12 03:22:12 字数 811 浏览 2 评论 0 原文

我目前正在为软件工程课程开发 ASP.Net MVC 项目。我的目标是创建一个小型在线游戏租赁系统。我目前有 3 张桌子,电影、游戏和注册者;我使用 LINQ-to-SQL 将每个表定义为我的模型的类。到目前为止,我已经创建了电影和游戏的模型,在创建注册者模型时我想做的是创建注册者与电影和游戏之间的关系。到目前为止,我尝试在 ID(Registrant 表中的主键)与电影和游戏中的 registrantID 字段之间定义一个外键。我意识到,如果我要删除注册者的实例,它将从其他表中删除关联的电影和/或游戏。我正在考虑做的是创建两个单独的模型来定义rentedGames和rentedMovies,并在它们与游戏和电影表之间创建关系,以便尝试对从商店租用/归还/购买电影或游戏的注册者进行建模。

总结:

到目前为止我所拥有的:

  • 3 个表:Registrants、Movies 和 游戏。
  • 我的 LINQ-to-SQL 模型 电影和游戏的库存。

我想要设置的内容:

  • 注册者租用/归还电影和/或游戏的模型,当租用/归还游戏时,会在库存中的项目旁边放置一个标志以指示其状态。

问题:

  • 将向模型添加单独的表 租借的电影/游戏阻止物品 在我的库存模型中定义 被删除??即,当客户归还租借的电影时,rentedMovie 实例将被删除,但电影库存中不会引用该电影。

  • 有没有相关的东西 表上设置了状态标志 相关条目,而不是 条目被删除,每当 另一个表中的关联条目 被修改了?? 电影中设置一个标志,表明该电影可供出租,然后rentedMovie 实例将被删除。

I'm currently working on an ASP.Net MVC project for a software engineering class. My goal is to create a small online game rental system. I currently have a 3 tables, Movies, Games and Registrants; and I'm using LINQ-to-SQL to define each of these tables as classes for my model. So far I've created models for Movies and Games, what I would like to do when creating the Registrant model is create a relationship between Registrants and Movies and Games. What I've tried so far is to define a foreign key between the ID (the primary key in the Registrant table) and a registrantID field in both the Movies and Games. What I realized is that if I were to remove an instance of a registrant, it will delete the associated movie and/or game from the other tables. What I'm thinking of doing is creating two separate models defining rentedGames and rentedMovies and creating a relationship between those and the Games and Movies table in order to try and model a registrant renting/returning/buying movies or games from the store.

In Summary:

What I have so far:

  • 3 tables: Registrants, Movies and
    Games.
  • LINQ-to-SQL models for my
    inventory of movies and games.

What I'm trying to setup:

  • A model for a registrant renting/returning a movie and/or game, when a game is rented/returned, a flag is placed next to the item in the inventory to indicate its status.

Question:

  • Will adding separate tables to model
    a rented movie/game prevent items
    defined in my inventory models from
    being deleted?? i.e. when a customer returns a rented movie, the rentedMovie instance is deleted, but not the movie is is referring to in the movie inventory.

  • Is there such a thing as a related
    table having a status flag set on the
    related entry, as opposed to the
    entry being deleted, whenever the
    associated entry in the other table
    is modified?? i.e. when a customer returns a rented movie, the rentedMovie instance sets a flag in the movie it refers to that it's available for rent, the rentedMovie instance is then deleted.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

美羊羊 2024-08-19 03:22:12

我会以不同的方式处理这个问题。首先,是否有真正的理由将电影和游戏视为单独的实体?为什么不拥有一个可以是电影、游戏、游戏机、蓝光播放器或其他任何东西的 RentableItem 呢?您可以通过 item_id 字段对其进行键入,并且它将具有预期的元数据(titletypegenrerental_class 等)。

然后,您需要对Registrant 租用一个或多个RentableItems 这一事实进行建模。这可以通过一个 Rental 表来完成,该表的每一行将一个已租用的 RentableItem 与特定的 Registrant(即 Rental rental_id 作为键,它有一个 RentableItem.item_id 的外键和一个 Registrant.registrant_id 的外键。 Rental 还会有到期日、“已归还”标志、租赁价格等。

如果有 RentableItem ,那么您就知道商店中没有 RentableItem item_id 与 RentableItem 相同且“returned”标志为 false 的租赁记录 您无需修改​​ RentableItem 表本身,只需修改 。租金表。

I'd go about this a bit differently. First, is there a real reason to treat a Movie and a Game as separate entities? Why not have a RentableItem that can be either a movie, a game, a game machine, a Blue-Ray player, or whatever? You'd key it by an item_id field, and it would have the expected metadata (title, type, genre, rental_class, and so on).

Then you need to model the fact that a Registrant rents one or more RentableItems. This can be done with a Rental table, whose rows each connect one rented RentableItem with a particular Registrant (that is, the Rental is keyed by a rental_id and it has a foreign key to RentableItem.item_id and a foreign key to Registrant.registrant_id. The Rental would also have the due date, a "returned" flag, the price of the rental, etc.

Then you know a RentableItem is not in the store if there is a Rental record whose item_id is the same as the RentableItem's and whose "returned" flag is false. You never have to modify the RentableItem table itself, just the Rental table.

圈圈圆圆圈圈 2024-08-19 03:22:12

您为rentedGames和rentedMovies创建单独的表是正确的,因为该模型现在允许同时租用多于一部相同类型的电影或游戏,这肯定比只有特定电影的一个实例更现实或游戏。

当删除链接记录(例如,rentedMovie)时,这将防止删除父记录。但是,如果您已将关系设置为非“级联删除”,并且允许原始电影或游戏表中的 registrantID 字段可为空,则无论如何都不会发生父电影的删除。

回答你的第二个问题(我意识到假设任何特定标题只有一部电影/游戏):如果你使用链接表(这就是你想要做的),通常完成此操作的方式就是简单地删除租用的电影/游戏记录。您的代码需要确定任何电影或游戏的链接记录的缺失,以便知道该电影或游戏现在可以(再次)出租。

You're right to create separate tables for rentedGames and rentedMovies, since this model now allows for more than one movie or game of the same type being rented at the same time, which is surely more realistic than having only one instance of a particular movie or game.

This will prevent the deletion of the parent record, when the link record (rentedMovie, say) is deleted. But this deletion of the parent movie should not be happening anyway if you've set up your relationship to not 'cascade delete', and you allowed the registrantID field in the original Movies or Games tables to be nullable.

To answer your second question (which I realise assumes only one movie/game for any particlar title): the way this is normally done, if you're using link tables, which is what you want to do, is simply to delete the rentedMovie/Game record. The absence of a link record for any Movie or Game is all your code needs to determine in order to know that that movie or game is now rentable (again).

沩ん囻菔务 2024-08-19 03:22:12

我知道您这样做是为了上课/练习,所以这可能不相关,但考虑到拥有物品的租赁历史通常非常有用。因此,您可能不想删除租用的记录,而只是将项目标记为已退回。

考虑一下:

TABLE RentalTransaction:
RentalTransactionID integer PK NOT NULL
CustomerID integer FK NOT NULL
RentedOn datetime NOT NULL
DueDate datetime NOT NULL
<..any other fields you may need..>

TABLE RentalItems:
RentedID integer PK NOT NULL
RentalTransactionID integer FK NOT NULL
RentedItemID integer FK NOT NULL
RentedQty integer NOT NULL
RentalRetuned datetime NULL

您可以通过 RentalReturned 字段是否为 null 来查看任何单个项目是否缺货。如果它为非空,那么您就知道该物品回来了,现在您可以汇总租赁数据以查看它出去的频率、平均租赁时间是多少等等。您必须构建一些检查才能进行当然,您租用的物品副本不会比您实际拥有的物品和其他此类物品多,但我认为这总体上是模式的更灵活的开始。对于你正在做的事情来说可能也过于复杂,但我至少想提出这个想法。

I know you're doing this for a class / practice, so this may not be relevant, but consider that having the rental history for things is often very useful. Because of this, you may not want to delete the rented records, but instead just mark the item as returned.

Consider:

TABLE RentalTransaction:
RentalTransactionID integer PK NOT NULL
CustomerID integer FK NOT NULL
RentedOn datetime NOT NULL
DueDate datetime NOT NULL
<..any other fields you may need..>

TABLE RentalItems:
RentedID integer PK NOT NULL
RentalTransactionID integer FK NOT NULL
RentedItemID integer FK NOT NULL
RentedQty integer NOT NULL
RentalRetuned datetime NULL

You can see if any individual item is out or not by if it's RentalReturned field is null or not. If it is nonull, then you know the item is back, and now you can aggregate rental data to see how often it goes out, what the average length of rental is, etc, etc. You would have to build in some checks to make sure you weren't renting more copies of an item than you actually have and other such things, but I think this is overall a more flexible start to a schema. It may also be overly complicated for what you're doing, but I wanted to at least bring the idea up.

情深已缘浅 2024-08-19 03:22:12

您确实要删除租用的电影实例吗?您将如何报告一个人租借了多少部电影等?

我建议稍微重新考虑一下你的模型。作为第一步,您需要在某个地方存储人员数据、在某个地方存储项目数据以及在某个地方存储人员/项目数据。

现在忽略电影和游戏之间的差异 - 一旦你定义了你的底层结构,这就会成为一个标准化的过程。

作为一个简单的起点,您应该具有:

Persons 1..1 ---- 1..* Hires 0..* ---- 1..1

其中 Hires 表是两个其他表之间的链接表的 项目由 personID、ItemID 和某种描述的时间戳组成的组合密钥(以允许重新租借同一部电影)。

然后,您可以考虑为项目类型等建立一个单独的表。

Do you really want to delete the rentedMovie instance? How will you report on how many movies a person has rented etc?

I'd suggest rethinking your model slightly. You need somewhere to store people data, somewhere to store item data and somewhere to store people/item data as a first step.

Ignore the difference between movies and games for now - that becomes a process of normalisation once you've defined your underlying structure.

As a simple starting point you should have:

Persons 1..1 ---- 1..* Hires 0..* ---- 1..1 Items

where the Hires table is a linking table between the two others with a combined key made up of personID, ItemID and a time-stamp of some description (to allow re-renting of the same movie).

You can then look at having a separate table for item types etc.

似最初 2024-08-19 03:22:12

首先要考虑的是,电影实际上是两个实体:标题和媒体。标题是“指环王”,而媒体是您带回家的 DVD。一份标题可以有多个媒体(副本),而一份媒体则有一份标题。 Rental 表针对每个媒体租赁都有一行,每次在租赁时扫描条形码时,此表都会获取一个新行,而 DateReturned 在归还时填充。 Media 表中的Status 字段跟踪每个光盘/游戏的输入/输出状态。
如果您觉得需要跟踪哪些电影一起租给了客户,您可能会发现通过 DateRented(日期时间)或添加 ReceiptNumberShoppingBasketID< /code> 到 Rental 表。

First thing to consider is that a movie is actually two entities, title and media. Title is "Lord of the Rings", while media is a DVD you take home. One title can have many media (copies), while one media has one title. Rental table has a row for each media-rental, this table gets a new row each time a bar code is scanned on rental, while DateReturned is populated upon return. Status field in the Media table tracks the in/out status for each disc/game.
If you feel that you need to track which movies were rented together to a customer, you may find that by DateRented (datetime) or add a ReceiptNumber or ShoppingBasketID to the Rental table.

gamerental_model_01

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文