是否存在针对不同数据类型使用不同表的数据库设计标准? [英] Is there a db design standard of using different table for different data type?

查看:97
本文介绍了是否存在针对不同数据类型使用不同表的数据库设计标准?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

最近,我遇到了关系数据库,其中每种数据类型都有自己的数据表。例如for string - TableVarchar,number - TableNumber etc.



我看到2个基于相同结构的调查数据库。无法理解为什么有人会像这样设计数据库。搜索谷歌标准,但找不到任何线索。



任何人都知道这是否是解决特定问题的标准方法?



更新1:201年9月17日 - 我可能找到了正确的原因,为什么数据库是这样维护的。这个数据库结构可用于许多小型应用程序,无需为数据访问层和数据库编写单行代码。

它可用于任何类型的Web应用程序,即调查,审计,员工管理,发票,电子商务,任何类型的管理网络应用程序,但小型的。



这个数据库结构可能被小型自由公司和团队用于发送他们的客户端应用程序在很短的时间内,只需构建一个前端应用程序就可以了。复制粘贴数据访问层和表格结构以及整个后端准备就绪。



希望这会对其他人有所帮助。



我尝试了什么:



搜索谷歌标准,但找不到任何线索。

Recently, I encountered relational databases where each data type has their own data table. for e.g. for string - TableVarchar, number - TableNumber etc.

I saw 2 survey database based on this same structure. not able to understand why would someone design the database like this. searched google for standard, but couldn't find any lead.

Anyone knows whether this is a standard way to solve a particular problem?

Update 1: 17-Sept-2018 - I am kind of probably found the right reason why the database was maintained like this. this database structure could be used for many small size applications without writing a single line of code for data access layer and database.
It can be used for any type of web application i.e. survey, audit, employee management, invoice, e-com, any kind of management web app but SMALL ones.

This db structure might be used by small freelance companies and team to ship their client app in very quick time, just build a front-end app and you are done. copy-paste data access layer and table structure and your whole back end ready.

Hope this would be helpful to others.

What I have tried:

searched google for standard, but couldn't find any lead.

推荐答案

Quote:

是否有针对不同数据类型使用不同表的数据库设计标准?

Is there a db design standard of using different table for different data type?



数据库设计不仅仅是数据结构,它的使用也很重要。

示例:

- 贵公司有订单数据库。 1表格看起来不够。

但是你有一个不断需要知道有效订单的过程,因为它试图减少浪费(钢梁切割)。

机会是持续的将全局数据库过滤为活动订单将比处理仅具有活动订单的辅助数据库更耗资源。

在这种情况下,由于使用,复制数据表将更有效。



其他注意事项可以考虑在内。


Databases design is more than the structure of data, its usage matters too.
Example:
- your company have a databases of orders. 1 table look enough.
But you have a process that continuously need to know active orders because it try to reduce waste (steel beam stock cutting).
Chances are that continuously filtering the global database to active orders will be more resources hungry than handling a secondary database with only active orders.
In this case, duplicating data tables will be more efficient because of the usage.

Other considerations can enter into account.


我可能找到了正确的原因,为什么数据库是这样维护的。这个数据库结构可用于许多小型应用程序,无需为数据访问层和数据库编写单行代码。

它可用于任何类型的Web应用程序,即调查,审计,员工管理,发票,电子商务,任何类型的管理网络应用程序,但小的。



这个数据库结构可能被小型自由公司和团队用来运送他们的客户端应用程序在很短的时间内,只需构建一个前端应用程序就可以了。复制粘贴数据访问层和表结构以及整个后端准备就绪。
I am kind of probably found the right reason why the database was maintained like this. this database structure could be used for many small size applications without writing a single line of code for data access layer and database.
It can be used for any type of web application i.e. survey, audit, employee management, invoice, e-com, any kind of management web app but SMALL ones.

This DB structure might be used by small freelance companies and team to ship their client app in very quick time, just build a front-end app and you are done. copy-paste data access layer and table structure and your whole back end ready.


这篇关于是否存在针对不同数据类型使用不同表的数据库设计标准?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆