I want to learn database management system on my own,would you like to suggest me some tips
我想自己学习数据库管理系统,你想给我一些提示吗?
7 个解决方案
#1
4
Don't try what others have suggested to "learn by doing".
不要尝试别人的建议“从实践中学习”。
That is monkey-style learning.
这是猴子式的学习。
Human intelligence/knowledge has gone far beyond the point where for the most specimens of the species, it is still possible/productive to "learn by making mistakes".
人类的智慧/知识远远超出了物种大多数标本的范围,“通过犯错误学习”仍然可行/富有成效。
Trust me, if you just go down the "learn-exclusively-by-doing" path, the only thing you will end up doing is repeating the same mistakes that millions have already made before you.
相信我,如果你只是沿着“独自学习”的道路走下去,你唯一能做的就是重复数百万人已经犯过的错误。
The only thing suggested in the other answers here that I can second, is "buy a good book". But "being a good book" does mean that it should give a thorough coverage of the theory. Otherwise you are likely to end up building database applications like the Romans built their aquaducts : by overdoing certain things "just to be on the safe side".
在其他答案中我唯一可以说的是“买一本好书”。但“做一本好书”确实意味着它应该对该理论进行彻底的报道。否则你很可能最终建立数据库应用程序,如罗马人建造他们的水道:过度使用某些东西“只是为了安全起见”。
(That is exactly what those Roman engineers did when they built those monuments that often still stand to this very day, in the absence of any knowledge/understanding of things such as gravity and the strenght of concrete spannings : they threw in a few dozens of extra bricks, without really knowing precisely whether they were really needed or not. But their world wasn't as economically competitive as ours.)
(这正是那些罗马工程师在建造那些通常仍然存在的纪念碑时所做的事情,在没有任何知识/理解重力和混凝土跨度等强度的事情的情况下:他们扔了几十个额外的砖块,并没有真正准确地知道它们是否真的需要它们。但是它们的世界并不像我们的那样具有经济竞争力。)
#2
3
I'm not a big fan of learning without an actual application to which it's applied.
没有应用它的实际应用程序,我不是学习的忠实粉丝。
Books on Modeling and Design are all well and good, but all of those suggestions need to be placed in the context of an application.
关于建模和设计的书籍都很好,但所有这些建议都需要放在应用程序的上下文中。
I have seen my share of "horrible" data models that work fine for the application. While there's a purity in having a "good design", the simple truth is that not everything needs a "good design". Or, better said, a "good design" for one application may be completely different than one for another.
我已经看到我的“可怕”数据模型的份额适用于应用程序。虽然有一个“良好的设计”的纯度,但简单的事实是,并非所有东西都需要“好的设计”。或者,更好地说,一个应用程序的“好设计”可能完全不同于另一个应用程序。
Many simple applications perform fine with "stupid", "dumb", "bad" designs.
许多简单的应用程序在“愚蠢”,“愚蠢”,“糟糕”设计中表现良好。
A lot of learning happens from doing the wrong thing.
做错了很多学习。
To paraphrase Thomas Edison, "Progress, I've made lots of progress. I know a thousand things that don't work."
用托马斯·爱迪生的话来说,“进步,我已经取得了很多进步。我知道有一千件事情都行不通。”
A lot of things are easier to learn when they're being applied in the "real world", and then judged against that metric of whether or not it's working or not vs simply holding it up to something read in a book, but unapplied.
当它们被应用到“现实世界”时,很多东西都更容易学习,然后根据它的工作与否的衡量标准进行判断,而不是简单地将它保持在书中读到的东西,而是未应用。
The benefit of "good design" is that it works well with the "Code has Momentum" meme, specifically that a bad design, once entrenched, is difficult to refactor or remove and replace with a good design, so you want to start with a good design up front.
“优秀设计”的好处在于它与“Code has Momentum”模因很好地配合,特别是一个糟糕的设计,一旦根深蒂固,难以重构或删除并替换为一个好的设计,所以你想从一个开始前面好的设计。
That said, as a corollary, especially if you follow blindly many books on modeling and architecture, you end up with simple applications that are terrible over engineered. With a lot of unnecessary code for circumstances that simply do not, and will not, exist in the application.
也就是说,作为必然结果,特别是如果你盲目跟随许多关于建模和架构的书籍,你最终会得到一些过于简单的应用程序。对于在应用程序中根本不存在和不存在的情况,有许多不必要的代码。
The game is finding the balance between "the perfect" solution, and the "workable solution".
游戏正在寻找“完美”解决方案与“可行解决方案”之间的平衡。
So, read all the books you like, but also apply it to something of value to you, and then fix your errors as you grow. Not everyone should start at ground zero, you want to "stand on the shoulder of giants", but it's important to understand, also, the paths the giants took in the first place to better appreciate why, and in what situations, they advocate their choices.
所以,阅读你喜欢的所有书籍,同时将它应用到有价值的东西上,然后随着你的成长修复你的错误。不是每个人都应该从零开始,你想要“站在巨人的肩膀上”,但重要的是要理解巨人们首先采取的路径,以更好地理解为什么,以及在什么情况下,他们提倡他们的选择。
#3
2
1) choose a target database, Oracle, MySQL, MS SQL... 2) buy a good book, 3) participate discussion in community. 0) of course, setup an env to play around...
#4
2
I too suggest you get a good book (or more, performance tuning is so complex a subject, it usually is covered in a separate book) on one of the major databases (whichever one you choose to learn first).
我也建议你在一个主要的数据库(无论你选择哪个首先学习的数据库)上得到一本好书(或更多,性能调整是一个如此复杂的主题,通常在一本单独的书中讨论)。
Subjects you need to learn are (at a minimum):
您需要学习的科目(至少):
Querying including the use of joins (if you do not thoroughly understand joins, you can't do anything except the simplest of queries or you may get a result set that is incorrect. You can't learn too much about joins.
查询包括使用连接(如果你没有完全理解连接,除了最简单的查询之外你不能做任何事情,或者你可能得到一个不正确的结果集。你不能学习太多关于连接。
If data is to have meaning, you must understand how to tell if the results you are producing are the correct results.
如果数据具有意义,您必须了解如何判断您生成的结果是否正确。
Normalization - if you don't understand normalization, you cannot design an effective relational database. Learn also about primary and foreign keys. Do not ever design a database table without a way to uniquely identify a record.
规范化 - 如果您不理解规范化,则无法设计有效的关系数据库。还要了解主键和外键。如果没有唯一标识记录的方法,就不要设计数据库表。
Set theory - you have to learn to think in terms of manipulating groups of records not looping through records one at a time.
集合论 - 你必须学会在操纵记录组方面思考,而不是一次一个地循环记录。
Performance - if you can't get results out in a timely manner, no one will use your software. Design in databases should consider performance carefully as databases as not so easy to refactor when they perform badly and there are many techiniques that are known to be faster than other techniques that produce the same result. You should learn what these are and not use the poorly performing ones because you find them easier to understand.
性能 - 如果您无法及时获得结果,则没有人会使用您的软件。数据库中的设计应该仔细考虑作为数据库的性能,因为当它们表现不佳时并不容易重构,并且有许多技术已知比产生相同结果的其他技术更快。您应该了解这些是什么,而不是使用效果不佳的,因为您发现它们更容易理解。
Data integrity - if you can't rely on the data to be correct, you do not have a useful database. You should know how to ensure that data has the correct values and relationships to other data. This also includes using the correct data type (Store dates as a datetime or date data type for instance).
数据完整性 - 如果您不能依赖数据是正确的,那么您就没有有用的数据库。您应该知道如何确保数据具有正确的值以及与其他数据的关系。这还包括使用正确的数据类型(例如,将日期存储为日期时间或日期数据类型)。
Security - including protecting against both SQL injection attacks and possible internal fraud.
安全性 - 包括防止SQL注入攻击和可能的内部欺诈。
Constraints and triggers and stored procs and user-defined functions.
约束和触发器以及存储过程和用户定义的函数。
Finally, do not use object-oriented thinking in database design. Relational databases often use tools and techniques that you would not use in Object-oriented programming. It is a a different subject and thus subject to different rules and constraints.
最后,不要在数据库设计中使用面向对象的思想。关系数据库通常使用您不会在面向对象编程中使用的工具和技术。它是一个不同的主题,因此受到不同的规则和约束。
#6
1
Try to do some simple applications using databases in your favorite programming language. Learn by doing. And when you get a problem, read the DBMS-documentation and learn.
尝试使用您喜欢的编程语言中的数据库做一些简单的应用程序。通过实践学习。当您遇到问题时,请阅读DBMS文档并学习。
#1
4
Don't try what others have suggested to "learn by doing".
不要尝试别人的建议“从实践中学习”。
That is monkey-style learning.
这是猴子式的学习。
Human intelligence/knowledge has gone far beyond the point where for the most specimens of the species, it is still possible/productive to "learn by making mistakes".
人类的智慧/知识远远超出了物种大多数标本的范围,“通过犯错误学习”仍然可行/富有成效。
Trust me, if you just go down the "learn-exclusively-by-doing" path, the only thing you will end up doing is repeating the same mistakes that millions have already made before you.
相信我,如果你只是沿着“独自学习”的道路走下去,你唯一能做的就是重复数百万人已经犯过的错误。
The only thing suggested in the other answers here that I can second, is "buy a good book". But "being a good book" does mean that it should give a thorough coverage of the theory. Otherwise you are likely to end up building database applications like the Romans built their aquaducts : by overdoing certain things "just to be on the safe side".
在其他答案中我唯一可以说的是“买一本好书”。但“做一本好书”确实意味着它应该对该理论进行彻底的报道。否则你很可能最终建立数据库应用程序,如罗马人建造他们的水道:过度使用某些东西“只是为了安全起见”。
(That is exactly what those Roman engineers did when they built those monuments that often still stand to this very day, in the absence of any knowledge/understanding of things such as gravity and the strenght of concrete spannings : they threw in a few dozens of extra bricks, without really knowing precisely whether they were really needed or not. But their world wasn't as economically competitive as ours.)
(这正是那些罗马工程师在建造那些通常仍然存在的纪念碑时所做的事情,在没有任何知识/理解重力和混凝土跨度等强度的事情的情况下:他们扔了几十个额外的砖块,并没有真正准确地知道它们是否真的需要它们。但是它们的世界并不像我们的那样具有经济竞争力。)
#2
3
I'm not a big fan of learning without an actual application to which it's applied.
没有应用它的实际应用程序,我不是学习的忠实粉丝。
Books on Modeling and Design are all well and good, but all of those suggestions need to be placed in the context of an application.
关于建模和设计的书籍都很好,但所有这些建议都需要放在应用程序的上下文中。
I have seen my share of "horrible" data models that work fine for the application. While there's a purity in having a "good design", the simple truth is that not everything needs a "good design". Or, better said, a "good design" for one application may be completely different than one for another.
我已经看到我的“可怕”数据模型的份额适用于应用程序。虽然有一个“良好的设计”的纯度,但简单的事实是,并非所有东西都需要“好的设计”。或者,更好地说,一个应用程序的“好设计”可能完全不同于另一个应用程序。
Many simple applications perform fine with "stupid", "dumb", "bad" designs.
许多简单的应用程序在“愚蠢”,“愚蠢”,“糟糕”设计中表现良好。
A lot of learning happens from doing the wrong thing.
做错了很多学习。
To paraphrase Thomas Edison, "Progress, I've made lots of progress. I know a thousand things that don't work."
用托马斯·爱迪生的话来说,“进步,我已经取得了很多进步。我知道有一千件事情都行不通。”
A lot of things are easier to learn when they're being applied in the "real world", and then judged against that metric of whether or not it's working or not vs simply holding it up to something read in a book, but unapplied.
当它们被应用到“现实世界”时,很多东西都更容易学习,然后根据它的工作与否的衡量标准进行判断,而不是简单地将它保持在书中读到的东西,而是未应用。
The benefit of "good design" is that it works well with the "Code has Momentum" meme, specifically that a bad design, once entrenched, is difficult to refactor or remove and replace with a good design, so you want to start with a good design up front.
“优秀设计”的好处在于它与“Code has Momentum”模因很好地配合,特别是一个糟糕的设计,一旦根深蒂固,难以重构或删除并替换为一个好的设计,所以你想从一个开始前面好的设计。
That said, as a corollary, especially if you follow blindly many books on modeling and architecture, you end up with simple applications that are terrible over engineered. With a lot of unnecessary code for circumstances that simply do not, and will not, exist in the application.
也就是说,作为必然结果,特别是如果你盲目跟随许多关于建模和架构的书籍,你最终会得到一些过于简单的应用程序。对于在应用程序中根本不存在和不存在的情况,有许多不必要的代码。
The game is finding the balance between "the perfect" solution, and the "workable solution".
游戏正在寻找“完美”解决方案与“可行解决方案”之间的平衡。
So, read all the books you like, but also apply it to something of value to you, and then fix your errors as you grow. Not everyone should start at ground zero, you want to "stand on the shoulder of giants", but it's important to understand, also, the paths the giants took in the first place to better appreciate why, and in what situations, they advocate their choices.
所以,阅读你喜欢的所有书籍,同时将它应用到有价值的东西上,然后随着你的成长修复你的错误。不是每个人都应该从零开始,你想要“站在巨人的肩膀上”,但重要的是要理解巨人们首先采取的路径,以更好地理解为什么,以及在什么情况下,他们提倡他们的选择。
#3
2
1) choose a target database, Oracle, MySQL, MS SQL... 2) buy a good book, 3) participate discussion in community. 0) of course, setup an env to play around...
#4
2
I too suggest you get a good book (or more, performance tuning is so complex a subject, it usually is covered in a separate book) on one of the major databases (whichever one you choose to learn first).
我也建议你在一个主要的数据库(无论你选择哪个首先学习的数据库)上得到一本好书(或更多,性能调整是一个如此复杂的主题,通常在一本单独的书中讨论)。
Subjects you need to learn are (at a minimum):
您需要学习的科目(至少):
Querying including the use of joins (if you do not thoroughly understand joins, you can't do anything except the simplest of queries or you may get a result set that is incorrect. You can't learn too much about joins.
查询包括使用连接(如果你没有完全理解连接,除了最简单的查询之外你不能做任何事情,或者你可能得到一个不正确的结果集。你不能学习太多关于连接。
If data is to have meaning, you must understand how to tell if the results you are producing are the correct results.
如果数据具有意义,您必须了解如何判断您生成的结果是否正确。
Normalization - if you don't understand normalization, you cannot design an effective relational database. Learn also about primary and foreign keys. Do not ever design a database table without a way to uniquely identify a record.
规范化 - 如果您不理解规范化,则无法设计有效的关系数据库。还要了解主键和外键。如果没有唯一标识记录的方法,就不要设计数据库表。
Set theory - you have to learn to think in terms of manipulating groups of records not looping through records one at a time.
集合论 - 你必须学会在操纵记录组方面思考,而不是一次一个地循环记录。
Performance - if you can't get results out in a timely manner, no one will use your software. Design in databases should consider performance carefully as databases as not so easy to refactor when they perform badly and there are many techiniques that are known to be faster than other techniques that produce the same result. You should learn what these are and not use the poorly performing ones because you find them easier to understand.
性能 - 如果您无法及时获得结果,则没有人会使用您的软件。数据库中的设计应该仔细考虑作为数据库的性能,因为当它们表现不佳时并不容易重构,并且有许多技术已知比产生相同结果的其他技术更快。您应该了解这些是什么,而不是使用效果不佳的,因为您发现它们更容易理解。
Data integrity - if you can't rely on the data to be correct, you do not have a useful database. You should know how to ensure that data has the correct values and relationships to other data. This also includes using the correct data type (Store dates as a datetime or date data type for instance).
数据完整性 - 如果您不能依赖数据是正确的,那么您就没有有用的数据库。您应该知道如何确保数据具有正确的值以及与其他数据的关系。这还包括使用正确的数据类型(例如,将日期存储为日期时间或日期数据类型)。
Security - including protecting against both SQL injection attacks and possible internal fraud.
安全性 - 包括防止SQL注入攻击和可能的内部欺诈。
Constraints and triggers and stored procs and user-defined functions.
约束和触发器以及存储过程和用户定义的函数。
Finally, do not use object-oriented thinking in database design. Relational databases often use tools and techniques that you would not use in Object-oriented programming. It is a a different subject and thus subject to different rules and constraints.
最后,不要在数据库设计中使用面向对象的思想。关系数据库通常使用您不会在面向对象编程中使用的工具和技术。它是一个不同的主题,因此受到不同的规则和约束。
#5
#6
1
Try to do some simple applications using databases in your favorite programming language. Learn by doing. And when you get a problem, read the DBMS-documentation and learn.
尝试使用您喜欢的编程语言中的数据库做一些简单的应用程序。通过实践学习。当您遇到问题时,请阅读DBMS文档并学习。