近年来，随着网络产业的飞速发展，人们的日常生活和工作方式也随之发生变化。许多旅游景区正在把常规的工作方式与因特网相融合，借助因特网的力量来提升管理者的工作能力。当前很多民宿预定系统工作都有很多问题，所以针对民宿预定系统的实际情况，提出可以针对民宿预定系统的应对办法，设计了一套能够有效地提升管理员工作效率的系统。
本系统利用Thinkphp和Uniapp技术进行开发民宿预定系统。本软件使用的编程语言是Php，以及从MySQL数据库中生成的数据，最后完成了一个比较完善的系统。该系统实现了民宿信息管理、民宿预定管理、民宿预定管理、民宿入住管理、民宿退房管理等功能。
关键词：民宿预定系统；Thinkphp；Php；MySQL数据库
Abstract
In recent years, with the rapid development of the network industry, People's Daily life and work have also changed. Many tourist attractions are integrating the conventional working mode with the Internet to enhance the working ability of managers with the power of the Internet. At present, there are many problems in the work of many homestay reservation systems. Therefore, according to the actual situation of the homestay reservation system, this paper puts forward some countermeasures for the homestay reservation system, and designs a system that can effectively improve the work efficiency of administrators.
This system uses Thinkphp and Uniapp technology to develop the hotel reservation system. This software uses the programming language is Php, as well as the data generated from the MySQL database, and finally completed a relatively perfect system. The system realizes the functions of information management, reservation management, reservation management, check-in management, check-out management, etc.
Key words: B&B reservation system; Thinkphp; Php; MySQL database
目 录
contents
1.3 Research status at home and abroad
2 Correlation technical analysis
2.4 Thinkphp Technology Introduction
3.2 System functional requirements
4 design and implementation of system
4.3.1 Conceptual model structure design
4.3.2 Physical model structure design
5.7 Housekeeping check-out management
5.8 Homestay information display
作者巍 luo5678123453
1 绪论
1.1 研究背景
近年来，随着旅游消费的不断升级和人们对旅游住宿体验的不断提高，民宿业已经成为了旅游行业中的一大热门。民宿作为一种新型住宿服务模式，相较于传统的酒店住宿，具有更加个性化、舒适、温馨的特点，深受旅游者的喜爱。
面对这个市场机遇，越来越多的创业者和企业开始进入民宿行业。而民宿预定系统作为民宿业务的重要组成部分之一，也逐渐成为了民宿企业必不可少的技术工具。民宿预定系统通过在线预订、支付、评价等功能，可以为民宿企业提供更加便捷、高效、安全的服务，也能为旅游消费者提供更加全面、优质、个性化的住宿体验[1]。
在这个背景下，民宿预定系统的开发和运营逐渐成为了民宿企业的一项重要工作。如何开发一个稳定、安全、易用的民宿预定系统，也成为了民宿企业需要面对的一个重要问题。
1.2 研究意义
民宿预定系统是一种方便、快捷的在线民宿预订平台，可以帮助旅客轻松预订自己满意的民宿，同时也为民宿经营者提供了便捷的管理和运营工具。这种系统的意义不仅在于提高了旅行者的预订效率和体验，还有以下几个方面：首先，民宿预定系统可以帮助旅行者更好地了解和选择符合自己需求的民宿。通过系统平台上的详细信息和图片，旅行者可以更好地了解民宿的位置、设施、服务等信息，从而做出更明智的选择。其次，民宿预定系统可以提高民宿经营者的管理和运营效率。通过系统平台上的预订管理和订单管理功能，民宿经营者可以更好地掌握客房预订情况和客户需求，及时调整经营策略和服务方式，提高经营效益[2]。
最后，民宿预定系统也有助于促进旅游业的发展。通过对旅游资源的整合和优化，民宿预定系统可以提高旅游者的满意度和体验感，进而促进旅游业的发展和繁荣。同时，民宿预定系统也为旅游业的数字化转型和升级提供了有效的切入点和工具。
1.3 国内外研究现状
随着互联网得发展，民宿预定系统成为一种越来越受欢迎的旅游住宿方式，随着人们对旅游品质要求的提高和对个性化需求的追求，民宿的市场需求日益增长。因此，民宿预定系统也成为了一个备受关注的热门话题。
国内外对民宿预定系统的研究已经相当深入。在国内，研究人员主要从多个方面进行了探讨，如系统架构、用户体验、营销策略等。例如，某些研究表明，系统的简单易用、信息的准确性和及时性、个性化推荐等因素会对用户预定决策产生重要影响。此外，营销策略也受到了广泛关注，包括如何提高平台的知名度、如何吸引更多的房东和用户、如何提高平台的交易量等方面。
在国外，民宿预定系统的研究同样也非常活跃。研究人员主要关注的是平台的商业模式、用户行为和市场趋势等方面。例如，一些研究表明，民宿预定系统在不同国家和地区的市场需求和用户行为存在差异，因此需要针对性的开展营销和服务。此外，还有研究探讨了平台如何提供更好的用户体验和如何利用大数据分析提高平台的竞争力等问题。
总体来说，民宿预定系统已经成为了旅游住宿市场的重要组成部分。国内外的研究表明，平台的简单易用性、信息的准确性和及时性、个性化推荐、营销策略以及用户体验等因素都是影响平台成功的重要因素。未来，随着技术的不断升级和用户需求的不断变化，民宿预定系统的研究将会继续深入。
1.4 主要内容
（1）本文提出了一套基于民宿预定系统的实现方法，根据总体的软件开发过程进行了初步的调查和研究，以决定该软件是否能够正常实现，技术是否可行，以及系统各功能组件的设计与开发，最终选定所采用的技术及实现方案。
（2）框架是一种由编程人员所提供的一组函数，它可以帮助开发者迅速建立起一个软件体系结构和重用能力，这个平台采用了一个开放源码的框架，它可以让开发者更快地建立起一个基础的开发框架，它可以让开发者在开发过程中，降低开发的困难，提高了系统的安全性和稳定性，并且可以让程序开发者进行系统的功能模块的开发和数据的处理。
（3）管理员对民宿预定系统的资料进行管理，既要有框架的规范，又要有某种基本的准则，利用MySQL中的限制关联，可以产生一个基于系统中各实体的关联的数据库表格，以便在执行该系统时设定各系统的关联[3]。
2 相关技术分析
2.1 MySQL数据库
MySQL数据库属于关系型数据库，性能较为优秀，目前隶属于Oracle旗下的公司之一。MySQL数据库通常应用在开发Web应用上，属于较为流行的数据库软件之一，可以将民宿预定系统的数据存放在数据库利用数据库SQL语句定义的表格当中，不用一定将数据存储在同一个地方，这样可以提高对数据库记录访问的速度并增加访问的灵活性。MySQL数据库语句可以被人们轻松理解，简单易用的特点使得较多中小型企业选择使用。MySQL使用的线程为多线程的形式，这有助于支持多处理器进行处理。MySQL通常能够使用高性能库代替函数库，这样可以提高对数据的访问。如果只是想要查询数据库里的数据的时候，一般不会分配内存资源。
数据库实际是一个容器，通过数据结构组织、存储和管理。数据库很大的一个作用为能够管理大量的数据并且提供解决方案。MySQL是较为典型的关系型数据库，具有的特点包括便捷和免费等，中小型Web项目大多数选择的是MySQL数据库。如果使用MySQL数据库会节约不少的成本，很多中小型公司也选择使用MySQL数据库作为公司的数据库。在IT领域当中MySQL为使用人数最多的开源关系数据库中的一种，使用率仅次于目前的Oracle数据库。
2.2 MVC模式
MVC是一种比较常用的软件开发方式，它可以将系统划分成模型、视图和控制器三个关键模块。在此流程中，该模式可以将民宿预定系统的所有资料进行打包，并与数据库表格进行对应，并可以使用SQL语句进行数据的操作，无需考虑到前端接口的处理。该视图层可以代表客户机的用户操作接口，可以将数据存储到前面的接口中，而视图层则要求相应的数据模式进行相应的处理。该控制器可以对由使用者提出的数据请求进行处理，并具有多种功能来使用。
2.3 微信开发者工具
微信开发者可以很容易的开发出一个微信应用，而更简单的界面描述语言，则可以开发出WXML和 WXSS。WXML和WXSS都是一种动态语言，它们可以在前端接口上显示数据，以便于使用者查看和方便来进行管理。功能方法可以通过在前端接口上单击对应的按键来回应使用者的要求等方面。功能的方式可以被写入js档，在将数据从前面接口传送到商业逻辑程序的过程中，这个js档会在数据库SQL声明的OS里对数据进行调用和应用。
2.4 thinkphp技术简介
thinkphp分别对应模型、视图和控制器，它们构成了MVC架构，在软件设计框架中称为模型。例如，使用该框架的组织代码可以实现业务逻辑和数据流的分离。MVC的思想是，当某个功能模块的业务逻辑需要改进时，前端接口的V层不需要重写业务逻辑，因为它的需求是自己决定的。在软件开发设计升级后，MVC(Model - View - Controller)被认为是优化改进的结果。其优点是将业务逻辑层的数据与系统、数据库交互的数据相分离，使Web的功能划分更加清晰和有保障。
2.5 B/S结构
B/S结构是将网页和服务器相结合的结构方法。是一种基于网络的网络结构模型，其前身为C/S结构。随着计算机科学和互联网科技的日益发达，B/S结构已经成为目前计算机体系结构的主流之一。它不仅可以很好地适应当今信息时代对计算机系统提出的新要求，而且还能满足人们对于信息传递的需求。在B/S框架中，用户的日常工作页面都是通过WWW网页实现的，重点是前台的UI表现以及后端的具体事件逻辑，为三层3-tier架构。在此架构下，系统维护与更新人员的工作量与成本压力获得一定程度的减轻，从而大大降低了系统的总体生产成本。这是因为所有人都能够在任何区域登录并以LAN、WAN、Internet/Intranet等方式实现数据库连接。使用B/S架构的一个最大优点就在于，它具有良好的可移植性，而且还具备强大的可扩展性和兼容性；其次，用户只需要拥有一台电脑即可。能够充分提高其服务器数据库的稳定性，有效地维护数据库系统和管理权限。在B/S结构的服务器端，像PHP之类的编程语言变得更快、更高效、更容易掌握。
B/S结构的产生，是因为传统的C/S结构已经不能适应全球网络开放、传播迅速和信息共享的新形势。因此，为了适应这种发展，就必须要采用一种全新的体系结构，即B/S结构。B/S模式的特点在于：1.分布性。2.开放性。3.可扩展性。4.安全性。B/S架构有很多好处，其中最突出的是，终端用户不能直接访问互联网以获得文本、音频、图片、动画、录像等，而是从网页端得到信息，因为数据存放在服务器中，而网页能够通过各种方法链接到数据服务器以交换信息。通常情况下，使用者无需借助任何的用户程式，就能直接从Web端上加载必须在本土安装的内容，而Web服务器则通过把数据或者消息发送到数据库服务器，然后将数据和其他信息返回到Web上，从而在这里进行下载。
3 需求分析
在软件开发过程中，需求分析是软件开发过程中的一个重要环节，首先要对软件的具体实施进行需求分析等方面的操作，然后从用户的视角进行深入的理解和分析。在需求分析中，可以准确地把握用户的真正需要和要求，从而使用户对其进行满意的管理等内容，但若不满足，则需要花费更多的时间和精力来进行设计。
3.1 可行性法分析
3.1.1 技术可行性
管理员有了这个管理软件，就可以对民宿预定系统进行管理，节约了大量的经费。为了有效地克服由于传统方式所造成的额外的财务开支，特别是在人员方面所造成的费用开支，本文对此进行了研究和探讨。由于采用传统的管理方式，不但耗费了大量的人员，还常常要求管理员进行人工记录。该系统的设计与实施旨在减少软件开发费用，节约管理员工作时间，增强用户体验。鉴于现有的因特网开放源码架构及软体装置，因此在经济性上是可以做到的[6]。
3.1.2 经济可行性
从需求分析到最终的设计和实施，所用的资金并不多，当民宿预定系统需要使用的时候，一部普通的计算机就能完成多方面操作，并且在一定的软件支持下，就可以正常工作了。管理员在运行民宿预定系统体系方面比较容易，这样就有了更多的时间来改进自己的系统体系。
3.1.3 社会可行性
本文所研制的民宿预定系统具有不违背法律、伦理层面、操作界面较为简便、便于用户使用的特点。由于电脑技术的飞速发展，电脑技术在旅游行业中的运用也越来越广泛，因而可以更好地为这次的民宿预定系统体系的开发打下坚实的基础[7]。
3.2 系统功能要求
3.2.1 用例概述
从软件的发展的观点看，最主要的是对软件的需求进行了研究，并对其进行了研究。只要能正确地进行需求分析和设计，就能节约大量的研发周期，加快研发进度。在对本系统的要求有了一定的认识以后，再根据不同的任务要求设定相应的函数，以使用户能够更好地利用这些特点来实现对系统的服务和管理等多方面的要求。
管理员用例图如图3-1所示。
图3-1 管理员用例图
Figure 3-1 Administrator use case diagram
商家用例图如图3-2所示。
图3-2 商家用例图
Figure 3-2 Business use case diagram
用户用例图如图3-3所示。
图3-3 用户用例图
Figure 3-3 User case diagram
3.2.2 用例分析
（1）登录
登录用例描述如表3-1所示。
表3-1 登录用例描述
Table 3-1 Login case description
| 用例标识 | 3.1 |
| 用例名称 | 登录 |
| 参与者 | 用户、商家、管理员 |
| 前置条件 | 用户、商家和管理员需要输入正确的用户名和密码 |
| 后置条件 | 登录 |
| 用例概述 | 用户、商家和管理员登录 |
| 基本事件流 | 1.用户、商家和系统管理员登录网页 2.管理员和使用者在系统中输入信息 |
| 备选事件流 | 4a 如果需要成功登录，必须输入与数据库信息相符的信息 |
| 备注 |
（2）个人中心
个人中心用例描述如表3-2所示。
表3-2 个人中心用例描述
Table 3-2 Description of the personal Center use case
| 用例标识 | 3.2 |
| 用例名称 | 个人中心 |
| 参与者 | 用户、商家和管理员 |
| 前置条件 | 用户、商家和管理员必须访问配置文件更改页 |
| 后置条件 | 修改个人信息 |
| 用例概述 | 用户和管理员管理个人信息 |
| 基本事件流 | 1.用户和系统经理登录网页 2.使用者及管理人员在该系统内输入使用者名称及密码 3.更改自己的个人信息到自己的个人信息更改页 |
| 备选事件流 | 4a 只有输入的信息合法才能够成功修改 |
（3）用户管理
在表格3-3中给出了用户管理案例的说明。
表3-3 用户管理用例描述
Table 3-3 Description of user management use cases
| 用例标识 | 3.3 |
| 用例名称 | 管理用户信息 |
| 参与者 | 管理员 |
| 前置条件 | 管理员必须输入正确的帐号和密码以登录该系统 |
| 后置条件 | 管理用户 |
| 用例概述 | 管理员管理用户 |
| 基本事件流 | 1.管理员输入用户名和密码 2.管理员点击添加按钮，在用户信息管理界面中提交新增加的用户信息 3.只有用户信息跟数据库信息不同，用户信息才能够添加成功 |
| 备选事件流 | 4a 添加的信息需要注意字符合法性才能够成功添加 |
| 备注 |
（4）商家管理
商家管理用例描述如表3-4所示。
表3-4 商家管理用例描述
Table 3-4 Merchant Management use case description
| 用例标识 | 3.4 |
| 用例名称 | 管理商家信息 |
| 参与者 | 管理员 |
| 前置条件 | 管理员必须输入正确的帐号和密码以登录该系统 |
| 后置条件 | 管理商家信息 |
| 用例概述 | 管理员管理商家信息 |
| 基本事件流 | 1.管理员输入用户名和密码 2.管理员点击修改按钮，在管理员信息管理界面上提交修改后的商家信息 3.商家信息修改成功 |
| 备选事件流 | 4a 修改的信息需要注意字符合法性才能够成功修改 |
| 备注 |
（5）民宿类型管理
民宿类型管理用例描述如表3-5所示。
表3-5 民宿类型管理用例描述
Table 3-5 Use case description of B&B type management
| 用例标识 | 3.5 |
| 用例名称 | 管理民宿类型信息 |
| 参与者 | 管理员 |
| 前置条件 | 管理员必须输入正确的帐号和密码以登录该系统 |
| 后置条件 | 管理民宿类型信息 |
| 用例概述 | 管理员管理民宿类型信息 |
| 基本事件流 | 1.管理员输入用户名和密码 2.管理员点击修改按钮，在管理员信息管理界面上提交修改后的民宿类型信息 3.民宿类型信息修改成功 |
| 备选事件流 | 4a 修改的信息需要注意字符合法性才能够成功修改 |
| 备注 |
（6）民宿预订管理
民宿预订管理用例描述如表3-6所示。
表3-6 民宿预订管理用例描述
Table 3-6 Use case description of hotel reservation management
| 用例标识 | 3.6 |
| 用例名称 | 删减民宿预订信息 |
| 参与者 | 管理员 |
| 前置条件 | 管理员登录系统 |
| 后置条件 | 删减民宿预订信息 |
| 用例概述 | 管理员删减民宿预订信息 |
| 基本事件流 | 1.管理员在系统中输入正确的帐号和密码 2.管理员按下删除键，将更改后的民宿预订资料提交至民宿预订管理界面 3.民宿预订信息删除成功 |
| 备选事件流 | 4a 民宿预订信息需要不与其他表格相联系，才能够删除民宿预订信息 |
| 备注 |
（7）查看民宿信息
查看民宿信息用例描述如表3-7所示。
表3-7 查看民宿信息用例描述
Table 3-7 Use case description of viewing B&B information
| 用例标识 | 3.7 |
| 用例名称 | 查看民宿信息 |
| 参与者 | 用户 |
| 前置条件 | 用户需要登录 |
| 后置条件 | 查看民宿信息 |
| 用例概述 | 用户查看民宿信息 |
| 基本事件流 | 1.用户登录网页 2.在这个系统中，用户键入一个自己拥有的用户名和密码 3.打开民宿信息清单的页面 |
（8）查看公告信息
查看公告信息用例描述如表3-8所示。
表3-8 查看公告信息用例描述
Table 3-8 Use case description of viewing bulletin information
| N用例标识 | 3.4 |
| 用例名称 | 查看公告信息 |
| 参与者 | 用户 |
| 前置条件 | 用户需要登录 |
| 后置条件 | 查看公告信息 |
| 用例概述 | 用户查看公告信息 |
| 基本事件流 | 1.用户登录网页 2.在这个系统中，用户键入一个自己拥有的用户名和密码 3.打开公告信息清单的页面 |
3.3 性能需求
因此，在进行民宿预定管理的过程中，不仅要考虑到民宿预定系统的功能要求，而且要考虑到系统的商业过程。
（1）相容
一般的软件系统，可以分为两个部分，一个是服务器，一个是客户端，一个是显示一个界面，主要是把一个电脑放在一个机房里，一个是软件开发人员平时要维护的方面，而这个界面，就是由一个客户端来操作的界面。要改善民宿预定系统的兼容性，就必须要注意在实现代码时，与前端接口之间的风格是否可以互相匹配。
（2）扩充
随着时间的流逝，软件系统会不断地进行系统的升级，这一点也是如此，当需求变化时，必须对其进行相应的功能的修改。在应用OOP方式的情况下，可以利用界面技术，严格按照软件的发展要求进行最终的系统的调整。
在今后的经营过程中，民宿预定系统的管理工作必须要适应不断改变的需求。从另一个方面来说，系统必须具备可扩充的能力。所以在开发过程中，必须要按照软件的规格来进行，这样才能方便地进行后续的修改。
（3）信赖度
软件必须有可靠度，不然许多实际的管理就会失败，导致无法进行有效的运行。系统的可靠程度主要体现在硬件能力、应用和数据等方面。一个系统的稳定性，意味着它可以从一个不正常的状态变成一个可以正常运转的系统，它的可用性和实用性都会得到提升。
（4）可用性
软件开发者在设计软件的过程中，不仅要确保软件的运行性能，还要尽可能地简化软件的运行，因为大部分的用户都不懂电脑，所以在设计过程中，如果把软件的功能设定得太过繁琐，会让大部分的用户无法使用。
4 系统的设计
对整体的系统进行了全面的需求剖析，然后再从系统的设计中引入各种功能。每一个人物都有自己的任务，而且针对各个系统的各个功能单元，都有自己的编码逻辑。一些复杂的要求在最后敲定之前必须进行修正和改进。
4.1 系统功能结构
只有在用户登录以后，才能够进行该系统的操作。使用者可以通过前面的介面键入使用者名称及口令进行登入。
图4-1 登录流程图
Figure 4-1 Login flowchart
在管理员输入了使用者名称和口令后，就可以在使用者的管理界面中管理使用者的资料。
图4-2 用户管理流程图
Figure 4-2 User management flowchart
系统管理员通过键入帐号和密码，可以进行民宿信息的管理操作。
图4-3 民宿信息管理流程图
Figure 4-3 Flowchart of homestay information management
4.2 功能模块
根据之前的各项设计分析，从系统的开发理念来看，系统可分为用户模块、商家模块和管理员模块。
用户模块主要是针对用户而设计，商家模块主要针对商家而设计，管理员模块是针对管理员而设计，而管理员可以对数据进行添加、删除、修改及查询等操作，相比之下管理员的权限是要大于用户和商家的权限的，所以管理员的功能会更多。
图4-4 功能模块图
Figure 4-4 Function module
4.3 数据库设计
在软件开发的过程中，数据库的设计是非常关键的一步，如果能够把数据库设计的很好，那么在进行数据库设计的过程中，一定要考虑到将来的数据表是否具有可扩展性。系统在不断发展的过程中，业务需求也会逐步变化，因此，需要对系统的功能进行调整。如果系统的功能发生了变化，那么相应的数据库就会相应地发生变化，所以在进行数据库设计时要考虑到以后的变化，所以在设计过程中要注意灵活性。由于数据库中的数据比较多，所以在使用MySQL时，并不需要像 Oracle这样的大型数据库。数据库引擎选择了InnoDB, InnoDB是一个对象类型的引擎。如果一个系统有多个表格要同时访问，则数据库引擎可以选择 InnoDB为主要方式。
4.3.1 概念模型结构设计
该民宿预定系统的功能设计模块是针对用户的需要而设定的，而系统的概念化模式则是建立一个对象的架构，这就是建立一个数据库的一个关键步骤。
（1）提供并回馈的资料，在处理资料时，既能符合使用者的基本需要，又能显示物件之间的某种相关性[8]。
（2）易于掌握。用户在使用民宿预定系统时，需要一个简单的操作系统，只有如此，才能更好地进行数据库的设计。
（3）当需要变化时，该系统可以迅速地对模型进行修改。
E-R图是一种用于描述概念模型的方法，它可以在已获得的数据模型的基础上，针对使用者的需要，设计出符合其要求的对象。
图4-5 数据库E-R图
Figure 4-5 Database E-R diagram
4.3.2 物理模型结构设计
（1）用户表
表4-1 用户表
Table 4-1 User list
| 列名 | 数据类型 | 长度 | 主外键 | 字段说明 |
| id | bigint | 20 | 是 | 主键 |
| addtime | timestamp | 0 | 创建时间 | |
| yonghuzhanghao | varchar | 200 | 用户账号 | |
| mima | varchar | 200 | 密码 | |
| yonghuxingming | varchar | 200 | 用户姓名 | |
| touxiang | longtext | 15 | 头像 | |
| xingbie | varchar | 200 | 性别 | |
| shoujihaoma | varchar | 200 | 手机号码 |
（2）商家表
表4-2 商家表
Table 4-2 List of vendors
| 列名 | 数据类型 | 长度 | 主外键 | 字段说明 |
| id | bigint | 20 | 是 | 主键 |
| addtime | timestamp | 0 | 创建时间 | |
| shangjiazhanghao | varchar | 200 | 商家账号 | |
| mima | varchar | 200 | 密码 | |
| shangjiamingcheng | varchar | 200 | 商家名称 | |
| tupian | longtext | 15 | 图片 | |
| lianxiren | varchar | 200 | 联系人 | |
| lianxidianhua | varchar | 200 | 联系电话 | |
| shangjiadizhi | varchar | 200 | 商家地址 |
（3）民宿信息表
表4-3 民宿信息表
Table 4-3 Homestays information table
| 列名 | 数据类型 | 长度 | 主外键 | 字段说明 |
| id | bigint | 20 | 是 | 主键 |
| addtime | timestamp | 0 | 创建时间 | |
| fangjianmingcheng | varchar | 200 | 房间名称 | |
| fangjiantupian | longtext | 15 | 房间图片 | |
| fangjianleixing | varchar | 200 | 房间类型 | |
| minsuxingji | varchar | 200 | 民宿星级 | |
| yiwanjiage | int | 11 | 一晚价格 | |
| minsudizhi | varchar | 200 | 民宿地址 | |
| lianxidianhua | varchar | 200 | 是 | 联系电话 |
| minsujieshao | longtext | 50 | 民宿介绍 | |
| shangjiazhanghao | varchar | 200 | 商家账号 | |
| shangjiamingcheng | varchar | 200 | 商家名称 | |
| clicknum | int | 11 | 点击次数 |
（4）民宿预订表
表4-4 民宿预订表
Table 4-4 Booking table of B&B
| 列名 | 数据类型 | 长度 | 主外键 | 字段说明 |
| id | bigint | 20 | 是 | 主键 |
| addtime | timestamp | 0 | 创建时间 | |
| yuyuebianhao | varchar | 200 | 预约编号 | |
| fangjianmingcheng | varchar | 200 | 房间名称 | |
| fangjiantupian | longtext | 15 | 房间图片 | |
| shangjiazhanghao | varchar | 200 | 商家账号 | |
| yiwanjiage | int | 11 | 一晚价格 | |
| ruzhuriqi | date | 10 | 入住日期 | |
| ruzhutianshu | int | 11 | 入住天数 | |
| zongjine | int | 11 | 总金额 | |
| yuyueshijian | datetime | 10 | 预约时间 | |
| ruzhuzhuangtai | varchar | 200 | 入住状态 | |
| beizhu | varchar | 200 | 备注 | |
| yonghuzhanghao | varchar | 200 | 用户账号 | |
| yonghuxingming | varchar | 200 | 用户姓名 | |
| shoujihaoma | varchar | 200 | 手机号码 | |
| sfsh | varchar | 200 | 是否审核 | |
| shhf | longtext | 0 | 审核回复 |
（5）民宿入住表
表4-5 民宿入住表
Table 4-5 Homestay occupancy table
| 列名 | 数据类型 | 长度 | 主外键 | 字段说明 |
| id | bigint | 20 | 是 | 主键 |
| addtime | timestamp | 0 | 创建时间 | |
| yuyuebianhao | varchar | 200 | 预约编号 | |
| fangjianmingcheng | varchar | 200 | 房间名称 | |
| fangjiantupian | longtext | 0 | 房间图片 | |
| shangjiazhanghao | varchar | 200 | 商家账号 | |
| yiwanjiage | int | 11 | 一晚价格 | |
| ruzhuriqi | date | 10 | 入住日期 | |
| ruzhutianshu | int | 11 | 入住天数 | |
| zongjine | int | 11 | 总金额 | |
| ruzhushijian | datetime | 10 | 入住时间 | |
| yonghuzhanghao | varchar | 200 | 用户账号 | |
| yonghuxingming | varchar | 200 | 用户姓名 | |
| shoujihaoma | varchar | 200 | 手机号码 | |
| userid | bigint | 20 | 是 | 用户id |
（6）民宿退房表
表4-6 民宿退房表
Table 4-6 B&B check-out list
| 列名 | 数据类型 | 长度 | 主外键 | 字段说明 |
| id | bigint | 20 | 是 | 主键 |
| addtime | timestamp | 0 | 创建时间 | |
| yuyuebianhao | varchar | 200 | 预约编号 | |
| fangjianmingcheng | varchar | 200 | 房间名称 | |
| fangjiantupian | longtext | 0 | 房间图片 | |
| shangjiazhanghao | varchar | 200 | 商家账号 | |
| yiwanjiage | int | 11 | 一晚价格 | |
| ruzhuriqi | date | 0 | 入住日期 | |
| ruzhutianshu | int | 11 | 入住天数 | |
| zongjine | int | 11 | 总金额 | |
| ruzhushijian | varchar | 200 | 入住时间 | |
| tuifangshijian | datetime | 10 | 退房时间 | |
| yonghuzhanghao | varchar | 200 | 用户账号 | |
| yonghuxingming | varchar | 200 | 用户姓名 | |
| shoujihaoma | varchar | 200 | 手机号码 | |
| crossuserid | bigint | 20 | 是 | 跨表用户id |
| crossrefid | bigint | 20 | 是 | 跨表主键id |
| userid | bigint | 20 | 是 | 用户id |
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
