STARTEAM以数据库为核心，是面向工程的管理方式。版本控制文件的文件名 由数据库管理，文件名不过是"指针"。方便文件在一个工程甚至同一个 Server Configuration的不同工程中的共享，以及任意移动和组织。

CVS,Perforce以文件为核心，即面向文件的管理方式，文件可以方便的重新 组合以及移植。原子化的Check In、二进制文件的版本控制是更Perforce的优势。 但是缺点是很难完成一个工程中，文件的移动及文件改名给前后不同版本/分支带来 问题；不当处理或者丢掉以前版本控制中的文件部署，或者增加由于文件冗余增加 占用空间。

STARTEAM的不利因素是很难将一个工程或者Server Configure中的文件分离、 组合、单独移植。其数据仓库 Repository像一个黑盒子，所有Project的所有版本 控制文件，都放在同一个目录下（Vault/Archive目录下，这是starteam的不足）。 目前缺乏良好的文件管理工具，是一个缺憾。

Starteam 一旦对文件进行版本控制，就丢入 Repository 目录中，很难在从中删除。 这应当看作是其最大的 BUG。

无论文件从哪个视图（根view，子view）添加目录和文件到starteam，在 该view下显示的文件夹和文件只不过是Vault/Archive目录下文件（以流水号作为 文件名），在数据库（starteam的管理核心）中的一个"指针"，删除文件，不过是 删除了"指针"，虽然没有真正删除文件，但是如果数据库中的所有关于某个文件的 "指针"都删除，文件只能通过历史来查看。但可以通过适当方法，通过历史的 "指针"重新找回版本控制。

文件在同一个视图中移动时，历史被保留；但当文件在不同视图中移动（注意不是删除） 时，原视图即使在历史中也找不到该文件，该文件从该视图中彻底消失了。如果将 一个视图彻底删除，如果该视图下文件没有在其他视图中建立共享的话，则造成文件 丢失，无法找回。

为防止此类事故的发生，经常备份，并设置任何人都没有工程和视图的删除 权限。