腰疼...我强烈建议不要老坐着，多变换姿势

作为资深(接近 30 年)近视患者,我有如下建议:
1. 所有 200 度或者以上的近视都需要定期验光并采取矫正措施
2. 近视眼镜应该在需要使用眼睛的时候保持佩戴。

柚子长得不错，尾巴为啥显得这么大?

我看回复的似乎都是纯粹的开发人员。
在下是多年工作经验的 BA,平时干的事情,在互联网行业叫做产品经理。
说到估时间,其实这是一个比较复杂的事情:
在项目管理理论里面,评估一件事情的工作量是很重要的工作,通常如果拿这个问题来问开发,基本上就是自己不知道该怎么评估,需要征求开发自己的意见。
开发都比较反感这事,因为在开发人员的思维里面,就一个原则:"我又不是先知，怎么能预测未来呢？"
时间评估也叫工作量预估,实际上是用来给项目经理计算项目(阶段)的预计持续时间的。这个时间的估计，通常会遵循一些管理方面的原则。
对于开发人员，我的建议如下:
任何人问你关于工作量的事情，你都要预估自己的能力和复杂程度,然后得出一个预估的可以完成的时间,接下来把这个时间周期乘以 3 或者 4。

一岁半不要乱吃水果,如果还在喝配方奶的阶段,就以配方奶为主食就好。
如果是已经进入混合喂养,保持食物多样性就好。
这么小的孩子其实是没什么维生素营养问题的，唯一需要注意的是维生素 D，补充的方法是晒晒太阳。

这个挺好的,其实写个雨后学 python，和雨后抓了只蜗牛回家，有多大区别？

不要管他,如实说就行了。你能在这里写这么长的句子描述状况，下家面试的时候如果给你出幺蛾子，直接照你写的句子说一遍就行。
要有自信,他还拿绳子给你捆上写代码不成？

这应该是可行的,并且对于所有的关系数据库都是可行的

我同意设计师的观点。这个没有必要对齐.......并且在 HTML 代码的级别，这种对齐可能还会带来开发上的麻烦,需要花费很多额外的精力

作为一个在传统应用领域经验丰富的 BA,我顶楼上 @aksoft 的。
其实最大的问题是什么叫做美？

我一直有个困惑，在下其实也就会写这样的代码，别的基本都不太会,正好借这个帖子顺便一问:
数据库应用程序基本就是 2 个思路:
1. 写一个特别复杂的查询，把所有的业务逻辑和计算都写在 SQL 里,一次性把结果拿出来显示。好处是只需要查询一次数据库,但是代码可重用性特别差。
2. 将这个查询分解成一系列的 Java/Python 代码,SQL 只负责读取需要的数据,业务逻辑和计算则由应用程序层完成,即所谓的 view 层。好处是代码可重用性比较好,但是可能查询数据库的次数会成(数十)倍增加。
选择这 2 种策略的原则到底是什么？有什么指导性的理论或者是书，又或者是最佳实践的文章不？
楼主这贴其实在我看来更适合后面的方法，因为从数据库返回的记录集很小，查询数据库的次数其实也很有限。即使分开，也没有什么致命的性能问题。

数据库脚本就是 SQL,全称是 Structured Query Language.
实际上就是用于关系数据库查询的专门语言，几乎所有的关系数据库系统都支持这种语言。

这个要取决于孩子的年龄,家与学校的距离,以及同一小区上学的孩子的数量。
我女儿上小学一年级开始,就没有接送了,因为学校离家的距离只有 400 米,并且路上都是比较热闹的街道。不会有无人区。

Oracle 自己有个工具,叫做"Oracle SQL Developer"。
这个支持用 JDBC 连接 Oracle, 连上之后右击数据库连接,选择"生成数据库文档"

这个问题本身需要进一步澄清:
假设: a = 'xy123sdasiioi' b = '123sdasiioi12'
你希望输出什么?

下面是扩展性比较好的设计:
1. 商品类型表 - 这个表只保存商品类型本身的信息,例如英文名字,ID,中文名字等等
2. 商品类型可能有的属性表: - 这个表保存商品具备的所有属性,你可能还需要一个表来维护属性的"属性"(主要给开发用)
3. 商品和商品类型的对应关系表: - 商品和商品类型的对应关系。
3. 商品对应的属性值表: - 保存商品与属性值对应关系。

不要进入有刺激性气味的场所,凡是你能闻到刺激性味道的气体,都可能对人体产生严重危害。
如果不能避免,建议佩戴防毒面具或者具备强大过滤功能的口罩。