That (at least during initial design), every Database Table (well, almost every one) should be clearly defined to contain some clearly understanable business entity or system-level domain abstraction, and that whether or not you use it as a a primary key and as Foreign Keys in other dependant tables, some column (attribute) or subset of the table attributes should be clearly defined to represent a unique key for that table (entity/abstraction). This is the only way to ensure that the overall table structure represents a logically consistent representation of the complete system data structure, without overlap or misunbderstood flattening. I am a firm believeer in using non-meaningful surrogate keys for Pks and Fks and join functionality, (for performance, ease of use, and other reasons), but I beleive the tendency in this direction has taken the database community too far away from the original Cobb principles, and we jhave lost much of the benefits (of database consistency) that natural keys provided.

那么为什么不两者都用呢?

代码就是设计

库克的格言随意收集……

The hardest language to learn is your second. The hardest OS to learn is your second one - especially if your first was an IBM mainframe. Once you've learned several seemingly different languages, you finally realize that all programming languages are the same - just minor differences in syntax. Although one can be quite productive and marketable without having learned any assembly, no one will ever have a visceral understanding of computing without it. Debuggers are the final refuge for programmers who don't really know what they're doing in the first place. No OS will ever be stable if it doesn't make use of hardware memory management. Low level systems programming is much, much easier than applications programming. The programmer who has a favorite language is just playing. Write the User's Guide FIRST! Policy and procedure are intended for those who lack the initiative to perform otherwise. (The Contractor's Creed): Tell'em what they need. Give'em what they want. Make sure the check clears. If you don't find programming fun, get out of it or accept that although you may make a living at it, you'll never be more than average. Just as the old farts have to learn the .NET method names, you'll have to learn the library calls. But there's nothing new there. The life of a programmer is one of constantly adapting to different environments, and the more tools you have hung on your belt, the more versatile and marketable you'll be. You may piddle around a bit with little code chunks near the beginning to try out some ideas, but, in general, one doesn't start coding in earnest until you KNOW how the whole program or app is going to be layed out, and you KNOW that the whole thing is going to work EXACTLY as advertised. For most projects with at least some degree of complexity, I generally end up spending 60 to 70 percent of the time up front just percolating ideas. Understand that programming has little to do with language and everything to do with algorithm. All of those nifty geegaws with memorable acronyms that folks have come up with over the years are just different ways of skinning the implementation cat. When you strip away all the OOPiness, RADology, Development Methodology 37, and Best Practice 42, you still have to deal with the basic building blocks of: assignments conditionals iterations control flow I/O

一旦你能真正地把自己包围起来，你最终会到达你想要的那个点 看(从编程的角度来看)编写库存应用程序之间的差别很小 一个汽车零部件公司，一个图形实时TCP性能分析仪，一个数学模型 一个恒星核心，或者一个约会日历。

初级程序员处理小块代码。随着经验的积累， 他们处理越来越大的代码块。 随着经验的增加，他们开始处理小块代码。

c++是一门很好的语言

一两个星期前，我说c++不是一种很好的语言，在另一个问题上我几乎被私刑了。现在我试着反过来说。；）

不，认真地说，我当时想说的是，c++有很多缺陷，现在我还会再试一次。这一点很难否认。它是如此的复杂，以至于学好它实际上是一件你可以奉献一生的事情。它使许多常见的任务变得不必要的困难，允许用户一头扎进未定义的行为和不可移植的代码的海洋，而编译器没有给出警告。

但它并不是许多人试图创造的那种无用、破旧、过时、令人讨厌的语言。它不应该被掩盖和忽视。没有它，世界不会变得更好。它有一些独特的优势，不幸的是，隐藏在古怪的语法，遗留的麻烦，尤其是糟糕的c++老师背后。但是他们就在那里。

c++有许多我在用c#或其他“现代”语言编程时非常怀念的特性。其中有很多c#和其他现代语言可以学习的地方。

它并没有盲目地专注于OOP，而是探索并开创了泛型编程。它允许惊人地表达编译时元编程，生成极其高效、健壮和干净的代码。在c#出现LINQ或lambda表达式之前，它从函数式编程中吸取了近十年的经验教训。

它允许您通过静态断言和其他元编程技巧在编译时捕获数量惊人的错误，这极大地简化了调试，甚至在某些方面胜过单元测试。(我宁愿在编译时捕获错误，而不是在之后运行测试时捕获错误)。

变量的确定性销毁允许RAII，这是一个非常强大的小技巧，使try/finally块和c#使用块变得多余。

虽然有些人指责它是“由委员会设计的”，但我会说，是的，它是，在这种情况下，这实际上并不是一件坏事。看看Java的类库。又有多少类被弃用了?有多少不应该使用?有多少是相互复制的功能?有多少设计糟糕?

C++'s standard library is much smaller, but on the whole, it's remarkably well designed, and except for one or two minor warts (vector<bool>, for example), its design still holds up very well. When a feature is added to C++ or its standard library, it is subjected to heavy scrutiny. Couldn't Java have benefited from the same? .NET too, although it's younger and was somewhat better designed to begin with, is still accumulating a good handful of classes that are out of sync with reality, or were badly designed to begin with.

c++有很多其他语言无法比拟的优点。这是一门很好的语言

C(或c++)应该是第一种编程语言

第一语言不应该是简单的，它应该是建立学生的思想，为严肃的计算机科学做准备的语言。 C语言是完美的，它迫使学生考虑内存和所有低级别的东西，同时他们可以学习如何构造代码(它有函数!)

c++有一个额外的优势，它真的很糟糕:)这样学生就会明白为什么人们必须想出Java和c#

不会编码的架构师是无用的。

这听起来有点苛刻，但并非不合理。如果你是一个系统的“架构师”，但对所使用的技术没有一定的实际参与，那么你如何获得开发团队的尊重呢?你如何影响方向?

架构师需要做更多的事情(与利益相关者会面，与其他团队谈判，评估供应商，编写文档，进行演示等等)但是，如果您从未看到架构师签入代码……小心!