数据库文档生成器

首先 你这个是一个广告帖..

另外我想说  这样的软件有很多..比如 "动软"就是其中的一个 根据数据库生成文档 相当之详细..

东软产生器的很垃圾好不好

首先 你这个是一个广告帖..

另外我想说  这样的软件有很多..比如 "动软"就是其中的一个 根据数据库生成文档 相当之详细..

Quote: 引用 2 楼 diaodiaop 的回复:

首先 你这个是一个广告帖..

另外我想说  这样的软件有很多..比如 "动软"就是其中的一个 根据数据库生成文档 相当之详细..

如果是广告贴，那么绝对是一个脑残的广告贴，因为广告的目标都没有出现。我更觉得是一个灌水帖。

Quote: 引用 2 楼 diaodiaop 的回复:

首先 你这个是一个广告帖..

另外我想说  这样的软件有很多..比如 "动软"就是其中的一个 根据数据库生成文档 相当之详细..

动软的很垃圾啊，详情看4楼
看看我的产生的怎么样

Quote: 引用 6 楼 zzu123zsw 的回复:

Quote: 引用 2 楼 diaodiaop 的回复:

首先 你这个是一个广告帖..

另外我想说  这样的软件有很多..比如 "动软"就是其中的一个 根据数据库生成文档 相当之详细..

动软的很垃圾啊，详情看4楼
看看我的产生的怎么样

或许对于你的用户来说，“挺好的”。请不要征询非你的用户的意见。如同你设计一种女性饰品，不要去找一些男性问这东西好不好一样。

我说了，这东西在程序员看来完全是很糟糕的东西。哪怕你导出一个xml的文档，并且用xslt添加这样的格式都比你这个强。用doc格式保存“文档”，使得文档丧失了编程性。一种不能集成到自动构建系统的文档生成工具是不会有什么实际价值的。

Quote: 引用 8 楼 caozhy 的回复:

Quote: 引用 6 楼 zzu123zsw 的回复:

Quote: 引用 2 楼 diaodiaop 的回复:

首先 你这个是一个广告帖..

另外我想说  这样的软件有很多..比如 "动软"就是其中的一个 根据数据库生成文档 相当之详细..

动软的很垃圾啊，详情看4楼
看看我的产生的怎么样

或许对于你的用户来说，“挺好的”。请不要征询非你的用户的意见。如同你设计一种女性饰品，不要去找一些男性问这东西好不好一样。

我说了，这东西在程序员看来完全是很糟糕的东西。哪怕你导出一个xml的文档，并且用xslt添加这样的格式都比你这个强。用doc格式保存“文档”，使得文档丧失了编程性。一种不能集成到自动构建系统的文档生成工具是不会有什么实际价值的。

谢谢你的回答，前一句很赞同，后一句讲的不怎么对啊。。。公司要求用Word 建立数据库说明文档，并且文档的说明源自数据库的注释字段，这就保证了文档和结构的一致性，并且该软件能够将注释字段写入数据库注释字段

呆在一个糟糕的公司中，你固然为创造一些应付公司垃圾规定的小程序沾沾自喜，但是这些东西放在一个更大的背景来看本身是毫无用处的。

比如说，你的公司敢在1~2小时内响应一个新的用户需求么？你可以灵活地修改数据库结构么？你可以通过版本系统同时维护多个分支，并且维护每个分支下的文档么？是的，你点一下就产生了一个“文档”。如果你的团队有10个人，每天构建3个版本，你的团队每个人手上都有一些大同小异，但是和实际数据库都有出入的“文档”，你知道哪个文档是最新的？你相信哪个文档的记载？

你编写代码，也许知道“DRY”，避免编写重复的代码。
你设计数据库，也许知道几个范式，避免数据的冗余。

重复意味着修改的扩散——当你打算修改某一个东西，必须修改它关联的全部重复的地方。

文档也是一样的道理。你的文档产生了大量的重复数据，只有字段的“中文名称”和“含义”，甚至只有“含义”是你文档比起你的数据库唯一向开发者多提供的信息。那么你的文档就不应该保存额外的重复的数据，以及花哨的格式。

Quote: 引用 11 楼 caozhy 的回复:

呆在一个糟糕的公司中，你固然为创造一些应付公司垃圾规定的小程序沾沾自喜，但是这些东西放在一个更大的背景来看本身是毫无用处的。

比如说，你的公司敢在1~2小时内响应一个新的用户需求么？你可以灵活地修改数据库结构么？你可以通过版本系统同时维护多个分支，并且维护每个分支下的文档么？是的，你点一下就产生了一个“文档”。如果你的团队有10个人，每天构建3个版本，你的团队每个人手上都有一些大同小异，但是和实际数据库都有出入的“文档”，你知道哪个文档是最新的？你相信哪个文档的记载？

这就叫做你不了解我的软件了，我的文档是通过数据库的结构和注释产生的，在一个时间内只要数据库结构动了，相应的注释和结构也应该有所变动，然后你只需要重新生成文档即可。如果没有这样的软件，在数据结构改变多次，如果有变更记录还好，但是将耗费大量的时间，如果没有的话，原来文档就没有任何参考价值，然后就不得不被丢弃了，然而你有了这个软件就可以，重新生成一个吗！省工，省时，省力。参考：http://wenku.baidu.com/view/c941109f6529647d27285265.html

Quote: 引用 12 楼 caozhy 的回复:

你编写代码，也许知道“DRY”，避免编写重复的代码。
你设计数据库，也许知道几个范式，避免数据的冗余。

重复意味着修改的扩散——当你打算修改某一个东西，必须修改它关联的全部重复的地方。

文档也是一样的道理。你的文档产生了大量的重复数据，只有字段的“中文名称”和“含义”，甚至只有“含义”是你文档比起你的数据库唯一向开发者多提供的信息。那么你的文档就不应该保存额外的重复的数据，以及花哨的格式。

中文名称和含义按一定格式一起保存到注释字段的

Quote: 引用 13 楼 zzu123zsw 的回复:

Quote: 引用 11 楼 caozhy 的回复:

呆在一个糟糕的公司中，你固然为创造一些应付公司垃圾规定的小程序沾沾自喜，但是这些东西放在一个更大的背景来看本身是毫无用处的。

比如说，你的公司敢在1~2小时内响应一个新的用户需求么？你可以灵活地修改数据库结构么？你可以通过版本系统同时维护多个分支，并且维护每个分支下的文档么？是的，你点一下就产生了一个“文档”。如果你的团队有10个人，每天构建3个版本，你的团队每个人手上都有一些大同小异，但是和实际数据库都有出入的“文档”，你知道哪个文档是最新的？你相信哪个文档的记载？

这就叫做你不了解我的软件了，我的文档是通过数据库的结构和注释产生的，在一个时间内只要数据库结构动了，相应的注释和结构也应该有所变动，然后你只需要重新生成文档即可。如果没有这样的软件，在数据结构改变多次，如果有变更记录还好，但是将耗费大量的时间，如果没有的话，原来文档就没有任何参考价值，然后就不得不被丢弃了，然而你有了这个软件就可以，重新生成一个吗！省工，省时，省力。参考：http://wenku.baidu.com/view/c941109f6529647d27285265.html

是啊，一旦修改了数据库结构，你需要重新生成文档（不能忘记这件事情），你需要把生成的文档分发出去（也不能忘记）。如果你的程序有多个分支，那么每个人手上必须有多个文档，收到文档后，他要知道这个文档是对应哪个分支的。

Quote: 引用 14 楼 zzu123zsw 的回复:

Quote: 引用 12 楼 caozhy 的回复:

你编写代码，也许知道“DRY”，避免编写重复的代码。
你设计数据库，也许知道几个范式，避免数据的冗余。

重复意味着修改的扩散——当你打算修改某一个东西，必须修改它关联的全部重复的地方。

文档也是一样的道理。你的文档产生了大量的重复数据，只有字段的“中文名称”和“含义”，甚至只有“含义”是你文档比起你的数据库唯一向开发者多提供的信息。那么你的文档就不应该保存额外的重复的数据，以及花哨的格式。

中文名称和含义按一定格式一起保存到注释字段的

如果文档是来自注释的，那么根本不需要文档了。我说了，就你面临的问题（不太正规的公司，没有几个人，无需频繁响应用户需求，也不需要同时开发多个项目，最关键的是老板让你们维护这种落后的文档），你的程序可以很好地解决。并且像你这样的需求，也有市场。但是放在一个更大的角度看，它的确没有什么用处。就是这样。

Quote: 引用 15 楼 caozhy 的回复:

Quote: 引用 13 楼 zzu123zsw 的回复:

Quote: 引用 11 楼 caozhy 的回复:

呆在一个糟糕的公司中，你固然为创造一些应付公司垃圾规定的小程序沾沾自喜，但是这些东西放在一个更大的背景来看本身是毫无用处的。

比如说，你的公司敢在1~2小时内响应一个新的用户需求么？你可以灵活地修改数据库结构么？你可以通过版本系统同时维护多个分支，并且维护每个分支下的文档么？是的，你点一下就产生了一个“文档”。如果你的团队有10个人，每天构建3个版本，你的团队每个人手上都有一些大同小异，但是和实际数据库都有出入的“文档”，你知道哪个文档是最新的？你相信哪个文档的记载？

这就叫做你不了解我的软件了，我的文档是通过数据库的结构和注释产生的，在一个时间内只要数据库结构动了，相应的注释和结构也应该有所变动，然后你只需要重新生成文档即可。如果没有这样的软件，在数据结构改变多次，如果有变更记录还好，但是将耗费大量的时间，如果没有的话，原来文档就没有任何参考价值，然后就不得不被丢弃了，然而你有了这个软件就可以，重新生成一个吗！省工，省时，省力。参考：http://wenku.baidu.com/view/c941109f6529647d27285265.html

是啊，一旦修改了数据库结构，你需要重新生成文档（不能忘记这件事情），你需要把生成的文档分发出去（也不能忘记）。如果你的程序有多个分支，那么每个人手上必须有多个文档，收到文档后，他要知道这个文档是对应哪个分支的。

只是简单的数据库文档，没有考虑多少分支问题！数据库是平面化的哦？

Quote: 引用 16 楼 caozhy 的回复:

Quote: 引用 14 楼 zzu123zsw 的回复:

Quote: 引用 12 楼 caozhy 的回复:

你编写代码，也许知道“DRY”，避免编写重复的代码。
你设计数据库，也许知道几个范式，避免数据的冗余。

重复意味着修改的扩散——当你打算修改某一个东西，必须修改它关联的全部重复的地方。

文档也是一样的道理。你的文档产生了大量的重复数据，只有字段的“中文名称”和“含义”，甚至只有“含义”是你文档比起你的数据库唯一向开发者多提供的信息。那么你的文档就不应该保存额外的重复的数据，以及花哨的格式。

中文名称和含义按一定格式一起保存到注释字段的

如果文档是来自注释的，那么根本不需要文档了。我说了，就你面临的问题（不太正规的公司，没有几个人，无需频繁响应用户需求，也不需要同时开发多个项目，最关键的是老板让你们维护这种落后的文档），你的程序可以很好地解决。并且像你这样的需求，也有市场。但是放在一个更大的角度看，它的确没有什么用处。就是这样。

虽然数据库支持注释，但是表现力毕竟没有文档强，如果考虑查找问题那就更加不方便了，而是用明确的文档可以帮助程序员解决这些问题。

Quote: 引用 18 楼 zzu123zsw 的回复:

Quote: 引用 16 楼 caozhy 的回复:

Quote: 引用 14 楼 zzu123zsw 的回复:

Quote: 引用 12 楼 caozhy 的回复:

你编写代码，也许知道“DRY”，避免编写重复的代码。
你设计数据库，也许知道几个范式，避免数据的冗余。

重复意味着修改的扩散——当你打算修改某一个东西，必须修改它关联的全部重复的地方。

文档也是一样的道理。你的文档产生了大量的重复数据，只有字段的“中文名称”和“含义”，甚至只有“含义”是你文档比起你的数据库唯一向开发者多提供的信息。那么你的文档就不应该保存额外的重复的数据，以及花哨的格式。

中文名称和含义按一定格式一起保存到注释字段的

如果文档是来自注释的，那么根本不需要文档了。我说了，就你面临的问题（不太正规的公司，没有几个人，无需频繁响应用户需求，也不需要同时开发多个项目，最关键的是老板让你们维护这种落后的文档），你的程序可以很好地解决。并且像你这样的需求，也有市场。但是放在一个更大的角度看，它的确没有什么用处。就是这样。

虽然数据库支持注释，但是表现力毕竟没有文档强，如果考虑查找问题那就更加不方便了，而是用明确的文档可以帮助程序员解决这些问题。

表现力和生成文档是两件事情。好比“数据库”表现能力不强，不代表你必须静态地、硬编码地去生成静态的网页。

Quote: 引用 17 楼 zzu123zsw 的回复:

Quote: 引用 15 楼 caozhy 的回复:

Quote: 引用 13 楼 zzu123zsw 的回复:

Quote: 引用 11 楼 caozhy 的回复:

呆在一个糟糕的公司中，你固然为创造一些应付公司垃圾规定的小程序沾沾自喜，但是这些东西放在一个更大的背景来看本身是毫无用处的。

比如说，你的公司敢在1~2小时内响应一个新的用户需求么？你可以灵活地修改数据库结构么？你可以通过版本系统同时维护多个分支，并且维护每个分支下的文档么？是的，你点一下就产生了一个“文档”。如果你的团队有10个人，每天构建3个版本，你的团队每个人手上都有一些大同小异，但是和实际数据库都有出入的“文档”，你知道哪个文档是最新的？你相信哪个文档的记载？

这就叫做你不了解我的软件了，我的文档是通过数据库的结构和注释产生的，在一个时间内只要数据库结构动了，相应的注释和结构也应该有所变动，然后你只需要重新生成文档即可。如果没有这样的软件，在数据结构改变多次，如果有变更记录还好，但是将耗费大量的时间，如果没有的话，原来文档就没有任何参考价值，然后就不得不被丢弃了，然而你有了这个软件就可以，重新生成一个吗！省工，省时，省力。参考：http://wenku.baidu.com/view/c941109f6529647d27285265.html

是啊，一旦修改了数据库结构，你需要重新生成文档（不能忘记这件事情），你需要把生成的文档分发出去（也不能忘记）。如果你的程序有多个分支，那么每个人手上必须有多个文档，收到文档后，他要知道这个文档是对应哪个分支的。

只是简单的数据库文档，没有考虑多少分支问题！数据库是平面化的哦？

看来你不懂什么是分支，简单来讲，比如你的软件分为1.0 2.0两个版本，或者分为专业版、企业版。那么你就需要多个分支。当你发现了一个bug，因为1.0 2.0都用到了某些代码，你需要同时修补，应用相同的更改，如果遇到这种问题，你会发现你的小工具可能是在帮倒忙。

你需要你的工具能和版本控制系统、自动构建系统集成。

Quote: 引用 19 楼 caozhy 的回复:

Quote: 引用 17 楼 zzu123zsw 的回复:

Quote: 引用 15 楼 caozhy 的回复:

Quote: 引用 13 楼 zzu123zsw 的回复:

Quote: 引用 11 楼 caozhy 的回复:

呆在一个糟糕的公司中，你固然为创造一些应付公司垃圾规定的小程序沾沾自喜，但是这些东西放在一个更大的背景来看本身是毫无用处的。

比如说，你的公司敢在1~2小时内响应一个新的用户需求么？你可以灵活地修改数据库结构么？你可以通过版本系统同时维护多个分支，并且维护每个分支下的文档么？是的，你点一下就产生了一个“文档”。如果你的团队有10个人，每天构建3个版本，你的团队每个人手上都有一些大同小异，但是和实际数据库都有出入的“文档”，你知道哪个文档是最新的？你相信哪个文档的记载？

这就叫做你不了解我的软件了，我的文档是通过数据库的结构和注释产生的，在一个时间内只要数据库结构动了，相应的注释和结构也应该有所变动，然后你只需要重新生成文档即可。如果没有这样的软件，在数据结构改变多次，如果有变更记录还好，但是将耗费大量的时间，如果没有的话，原来文档就没有任何参考价值，然后就不得不被丢弃了，然而你有了这个软件就可以，重新生成一个吗！省工，省时，省力。参考：http://wenku.baidu.com/view/c941109f6529647d27285265.html

是啊，一旦修改了数据库结构，你需要重新生成文档（不能忘记这件事情），你需要把生成的文档分发出去（也不能忘记）。如果你的程序有多个分支，那么每个人手上必须有多个文档，收到文档后，他要知道这个文档是对应哪个分支的。

只是简单的数据库文档，没有考虑多少分支问题！数据库是平面化的哦？

看来你不懂什么是分支，简单来讲，比如你的软件分为1.0 2.0两个版本，或者分为专业版、企业版。那么你就需要多个分支。当你发现了一个bug，因为1.0 2.0都用到了某些代码，你需要同时修补，应用相同的更改，如果遇到这种问题，你会发现你的小工具可能是在帮倒忙。

你需要你的工具能和版本控制系统、自动构建系统集成。

你研究的是代码，我研究的是数据库，不是一码事哦！