如何将ACCESS的表和查询创建成动态的WEB？

Posted 2023-04-30

情况说明：本人负责公司图书借阅的ACCESS数据库。原来的做法是在一台电脑上编辑ACCESS文件，然后复制到局域网的公共硬盘上，公司内部电脑可以打开该文件。
存在问题：1、该公共硬盘没有权限设置，任何人都可以访问并随意修改。
2、很多员工的电脑没有安装ACCESS，部分员工完全不会使用ACCESS。
设想目标：1、架设一个web站点，在公司局域网内部可以访问该站点。
2、将主机上的ACCESS表和查询导出成动态的适合用户界面的html文件，架设到web站点上。主机有修改HTML的权限，而访问者只有查询的权限，没有修改的权限。
求助：目标1本人可以求助网管。但是目标2就要靠自己。ACCESS表导出静态的HTML很容易，要把“查询”导成动态的HTML，还要添加用户界面，在网页上实现交互,本人水平有限，实在力不从心。
请问：要实现以上目标有几种方式？此情况下用 javascript实现web的控制是否可行（本人对脚本语言粗通）？请高手指点。有Javascript现成的实例最好，如果没有，推荐几个好的适合初学者的网站（最好能够交流和提问的），本人一样感激不尽。

有两个方案：
1.利用access 生成数据访问页，把数据访问页发布到web服务器上，实现交互式访问
2.假如你不会asp 可以调用frontpage的"数据库界面向导"自动生成asp文件，经过简单修改后发布即可。 参考技术A 去用 ASP 吧，如果你真的是一个 ACCESS 开发者，从 ACCESS 转到 ASP 1天学习时间足够了。 参考技术B 架设IIS+ASP编程，想怎么玩就怎么玩。

动态增加数量的可行性。数据库中的表和行 [重复]

【中文标题】动态增加数量的可行性。数据库中的表和行 [重复]

【英文标题】：Feasibility of dynamically increase in no. of tables and rows in a database [duplicate]

【发布时间】：2011-09-19 05:21:48

【问题描述】：

可能重复：Insert many rows to one table OR insert rows separately to many table?

100个10000行的表和1000个1000行的表哪个更好？

上面的问题只是一个基础，没有以下条件是不能完成的。

条件：

R1-编号第一种情况下的行数。 R2-编号第二种情况下的行数。 T1-No.第一种情况下的表格。 T2-编号第二种情况下的表格。 R1 和 R2 动态（急剧）增加，超过给定限制的样本。 T1 是恒定的。 T2 动态增加（与 r1 成正比） 不关心表管理和数据库的简单性。

只对最短查询执行时间和最短服务器加载时间感兴趣。

数据库 - MySql

语言 - PHP

问题：

查询执行时间和服务器加载时间（最低 RAM 使用量）。 动态增加编号的可行性。数据库中的表。 动态增加编号的可行性。表中的行数。

除了答案之外，还邀请了上述数据库技巧。

【问题讨论】：

1 带有1,000,000 行的表。

请阅读以上问题/答案：***.com/questions/5999641/…如果和您遇到的问题类似，则无需进一步搜索。将表的数量保持在标准化所需的最低水平（5、40、100，无论您需要什么），但保持不变，让行数无限增长。

thedailywtf.com/Articles/Confessions-The-Shopping-Cart.aspx

这看起来又是一个骗子。老实说，人们会尝试自己做功课。如果你在学习过程中作弊，你就无法在专业上取得成功。

谁说这是家庭作业。我把这个问题做成了任何人都可以理解的方式。

【参考方案1】：

您的问题有很多，如果有更多信息会有所帮助，但以下是我的一些想法：

与数据库接口的语言通常不是一个因素——您应该尽可能地努力限制所需的连接和消息的数量（即使用连接而不是与 PHP 通信两次），但是因为好的设计正在做尽可能多地在 DB 端进行数据选择/排序工作（因为 that's what they're for） 如果所有表都具有相同的结构，那么在处理大量选择时通常最好使用一个表 - UNION，至少在我的经验中，通常是一个缓慢的野兽。 如果您真的很担心一次只访问一小部分数据，那么我建议您将所有内容保存在更少的表中并创建视图。 Don't care about table management and simplicity of database 是一个糟糕的政策。所有编程的最佳实践都适用于数据库设计。请记住，不知道您的想法的人将继承此项目，而这可能就是您。

就个人而言，我认为我们中的很多人都曾使用过 1M 线表，而且我知道我不想将其作为一系列UNIONs、@987654325 来处理@s 和 JOINs。至少，当它都是相同的表设计时，不是。

【参考方案2】：

既然一百万行是一个很小很小的表，为什么还要考虑将它分成 100 个表或 1000 个表？