有关杜邦钛白粉项目落户山东中的环境问题 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Environmental - 环境科学与工程

有关杜邦钛白粉项目落户山东中的环境问题

有关杜邦钛白粉项目落户山东中的环境问题# Environmental - 环境科学与工程

i*i2008-01-22 08:01

1 楼

以前学另外一个学科的PhD,找工作的时候换了一个行业，
可谓风牛马不相及，
2片Journal, 第二作者 PhD 老板恶心不让我第一，两个加起来引用76
13片工作行业conference, 其中5个一作，
工作行业3片review, conference review 10个，引用12个，都是他引
工作行业patent 3个，都不是第一作者，
EB1B似乎好像还成，能裸上EB1A吗

h*92008-01-22 08:01

2 楼

由于第一次到国外在商场买了一口铁锅和别的东西大约20多美金。由于不等外语，又没
有服务员就拿着东西到下一层去准备买别的东西。结果被商场保安误以为是偷窃，要罚
款150元。不服判决最后法官认定不是偷窃是因为语言不通造成的误会，撤消了原来的
罚款决定。
请问这会不会影响485 绿卡申请？
多谢

y*92008-01-22 08:01

3 楼

I have read "As a rule of thumb, every table should have a clustered index"
(see http://www.sql-server-performance.com/2007/clustered-indexes/ )
Isn't this a really general rule? Do your production database tables follow
this?
If I understand correctly, this feature corresponds to "Index organized
table" (IOT) in Oracle, generally IOT could be good for look up talbe in
Oracle.
But I have never seen similiar recommendation in Oracle. Interested in
knowing why or whether it is really good to have clustered index in every
table
Denis
Oracle DBA

f*g2008-01-22 08:01

4 楼

我的一个朋友向我咨询杜邦钛白粉项目落户山东中的环境问题，我不是这个专业的，很
多东西不懂，请这里的大侠们给一些建议。谢谢！下面是南方周末上发表的文章。

i*u2008-01-22 08:01

5 楼

绝对不会,放心.

c*d2008-01-22 08:01

6 楼

不要被名字迷惑了
oracle cluster-index table和ms sql server中的cluster index不是一个概念

f*g2008-01-22 08:01

7 楼

投资47亿年产20万吨规模超过国内任何一家钛白粉企业
一个曾被台湾鹿港居民拒绝的化工项目，22年后漂洋过海落户山东东营，这个杜邦在美
国以外最大的投资项目引发了国内同行的广泛质疑，除了竞争压力，他们还担心该项目
存在环保隐患
杜邦工厂距全国最大的河口三角洲自然保护区黄河三角州湿地25公里　向春/制图
从山东省东营市中心向东开车13公里，就可到达一片海边的盐碱地。到2008年底，
这片荒芜的土地上将诞生出一个世界级的化工厂。
美国杜邦集团将为这个工厂投资6.4亿美元（约47亿人民币），这是它迄今为止在
美国以外最大的单笔投资。工厂主要生产氯化法钛白粉，一种被广泛应用于涂料、塑料
和造纸等行业的白色颜料。
等明年工厂投产后，预计它将给东营市每年增加5亿元的税收，并创造600个就业岗
位，这还没算上杜邦改善工厂周边交通所花的钱。总之，对东营市来说，单从经济效益
看，这绝对是一笔好买卖。
所以从2005年11月和杜邦签订合作协议之后，东营市一直十分积极，但由于工厂使
用的氯化法工艺和钛原料含有放射性对环境有较大的影响，直到今年11月，经过两次测
评之后，环

L*82008-01-22 08:01

8 楼

///

y*92008-01-22 08:01

9 楼

As far as I know, there are following types of tables in Oracle
- Heap organized tables ( default one, > 99% tables are this type in oracle
applications, in fact I did not see any of my production databases use any
other type of tables yet except for temporary tables - I use it, developers
have no idea about temporary tables in my work place)
- Index organized tables (IOT)
- Index clustered tables
- Hash clustered tables
- Sorted hash clustered tables
- Nested tables
- temporary tables
- Object tables
- External tables
I am pretty sure that if a SQL server table has a clustered index, such a
table corresponds to IOT in Oracle. I am not sure what do you mean by "
oracle cluster-index table". Forget who says it wrt Oracle application- it
says if your application only use Heap organized table, it means you have a
poor design. But my doubts is in SQL sever if it is recommended every table
should have a clustered index, this sounds too much to me from Oracle
perspective.

【在 c*****d 的大作中提到】

: 不要被名字迷惑了
: oracle cluster-index table和ms sql server中的cluster index不是一个概念

f*g2008-01-22 08:01

10 楼

台湾之鉴
从杜邦项目再向北25公里，就是全国最大的河口三角洲自然保护区——黄河三角洲
湿地，黄河由此入海，东北亚内陆和环西太平洋鸟类迁徙由此中转，当地风光优美，东
营市的市民也因此自豪。
但绝大部分市民并不清楚，今后他们的脚底之下，可能是一个巨大的废液灌注区。
一些知道内情的市民开始在网络发帖上抵制杜邦项目。
让人未曾想到的是，22年前，杜邦亦曾计划到台湾沿海的彰化县鹿港镇附近设厂，
使用同样的工艺和同样的原料——二氧化钛含量为60％的低品位矿，废料则抛弃至深海。
1985年，台湾《联合报》报道杜邦计划在漳滨工业区投资64亿台币，设钛白粉厂。
几百字的消息，马上引起了民众的激烈反应。
漳滨工业区毗邻鹿港镇，当地居民以渔业为生，害怕废水处理会导致海水污染加剧
；宗教和文化人士则担心，会对文物保护和传统习俗不利。
随后，在当地居民李栋梁的带领下，当地民众、环保社团、专家、大学生联合掀起
了一场台湾历史上最著名的环保运动。这起事件也成为了台湾环保运动的滥觞。“我们
从订阅的日本资讯中，了解到杜邦某个工厂导致了臭氧层的破坏，被美国环保人士披露
，

v*r2008-01-22 08:01

11 楼

You understanding is right, Oracle IOT serves the same purpose as clustered
index in SQLServer (only difference is you can view IOT is PK only clusted
index). Whatever advantage and disadvantage to use IOT applies to clustered
index in SQLServer, so obviously, it is NOT true "As a rule of thumb, every
table should have a clustered index".

"
follow

【在 y****9 的大作中提到】

: I have read "As a rule of thumb, every table should have a clustered index"
: (see http://www.sql-server-performance.com/2007/clustered-indexes/ )
: Isn't this a really general rule? Do your production database tables follow
: this?
: If I understand correctly, this feature corresponds to "Index organized
: table" (IOT) in Oracle, generally IOT could be good for look up talbe in
: Oracle.
: But I have never seen similiar recommendation in Oracle. Interested in
: knowing why or whether it is really good to have clustered index in every
: table

f*g2008-01-22 08:01

12 楼

行业冲击
11月26日，在四川攀枝花举行的2007钛白粉行业年会的开幕式一结束，协会的近十
名理事会成员就聚在了一起，商议如何向相关部门反映杜邦项目存在的问题，包括山东
东佳、江苏钛白等国内钛白粉领头企业的负责人都参加了这次“小会”。
因为20万吨的杜邦项目一旦投产，其年产量将超过目前中国任何一家钛白粉厂家，
对于已经供大于求的国内钛白粉行业来说，无疑是一记重锤。
根据这次年会论文集提供的数据，2007年我国的钛白粉年总产能127万吨，但总需
求只有100万-120万吨，未来两三年还有200万吨项目上马，供给已远远大于需求。
为了打消国内同行的担忧，杜邦曾专门在项目申请报告中表示：“杜邦未来的竞争
对手主要是国际上其它二氧化钛生产商，与中国国内企业不构成竞争。”
钛白粉行业协会秘书长郭正龙对此并不认同：“根据他们（杜邦）提供的数据，60
%的产品都与国内通用型产品相同，而且是国内刚发展起来的中高端产品，怎么会不构
成竞争？”
其实早在2006年5月，杜邦在网上对东营项目环境影响评价进行第一次公示时，郭
正龙已有所行动。无奈的是，公示中并没

y*92008-01-22 08:01

13 楼

If I have a one-million row table without any index, let's say it has a col
called SSN and its values are unique. now i create a clustered index on SSN,
what will happen to the existing table rows?
For example, let's say each page can only hold two rows, at the begining,
rows with ssn=1 and ssn=4 are in page no 1; rows with ssn=2 and ssn=3 are in
page no 2. now i create a clustered index on ssn col, at the end will
page no1 contains ssn=1,2 and page no 2 contains ssn= 3 and 4 ?

f*g2008-01-22 08:01

14 楼

12月20日，《南方周末》发表了一篇题为“杜邦钛白粉项目落山东曾因环保隐患遭台
湾拒绝”的文章，报道称，杜邦公司在山东东营的投资项目引发了国内同行的广泛质疑
，除了竞争压力，他们还担心该项目存在环保隐患。
就此，杜邦中国集团有限公司向新浪财经发来声明，以下为声明全文：
有关杜邦钛白科技中国(东营)项目
【重点讯息】
1.《南方周末》2007年12月20日发表的有关该项目的报道，所反映的观点均来自国
内钛白粉生产厂家，有失偏颇，不利于公众客观、全面地了解杜邦钛白生产技术以及计
划中的中国投资项目。
2.在安全和环保等领域，杜邦公司一直奉行其企业核心价值观，具有强烈的社会责
任感，并拥有专业技术特长，堪称全球企业表率。
3.杜邦计划中用于东营项目的生产工艺和环境技术将为中国带来先进的氯化法钛白
粉生产技术，促进国内钛白粉行业的产业升级，整体减小钛白粉行业对环境和能源的影
响；并引进先进的深井灌注技术，开启第四维环境容量，缓解地面环境压力，为国家节
能减排和可持续发展的大方向提供战略性技术方案选择和储备。
杜邦公司概况
成立于1802年的杜邦公司是一家科学企业，致力于利用科学创造可持续的解

y*92008-01-22 08:01

15 楼

@vbitter,
Further reading ...
In SQL server, if a table does not contain a clustered index, when we create
a primary key constraint, SQL server will use the primary key column for
the clustered index key.
So I think we all agree, in most cases, a table should have a primary key,
no matter in oracle or in sql server.
I checked the AdventureWorks sample db in sql server, I saw > 99% table has
clustered index and most is also PK.
So I guess the rule of thumb is likely true in sql server.

clustered
clustered
every

【在 v*****r 的大作中提到】

: You understanding is right, Oracle IOT serves the same purpose as clustered
: index in SQLServer (only difference is you can view IOT is PK only clusted
: index). Whatever advantage and disadvantage to use IOT applies to clustered
: index in SQLServer, so obviously, it is NOT true "As a rule of thumb, every
: table should have a clustered index".
:
: "
: follow

m*e2008-01-22 08:01

16 楼

在所有在华有投资的外企中，杜邦在环境方面的表现属于比较好的那一类，不过不清楚
山东这个项目的具体情况，要是能把相关的环评报告找来看看就好了

v*r2008-01-22 08:01

17 楼

PK column is not necessarily the most frequently used query criteria when
querying a table, so I guess it is common to use non-pk index as the
clustered index in sqlserver.
Not sure why clustered index is heavily used in SQLServer, it might be bad
application/table design, less power features in SQLServer, or maybe both.
In Oracle, you have more flexible way to group row data logically together (
Partition) instead of having to use physical method like IOT, which is un-
relational in nature and only applied to certain scenarios.

create
has

【在 y****9 的大作中提到】

: @vbitter,
: Further reading ...
: In SQL server, if a table does not contain a clustered index, when we create
: a primary key constraint, SQL server will use the primary key column for
: the clustered index key.
: So I think we all agree, in most cases, a table should have a primary key,
: no matter in oracle or in sql server.
: I checked the AdventureWorks sample db in sql server, I saw > 99% table has
: clustered index and most is also PK.
: So I guess the rule of thumb is likely true in sql server.

y*92008-01-22 08:01

18 楼

Just find an insteresting blog that seems addressing exactly same doubts:
"So how is it you can have good perf in Oracle, w/o IOTs, but in SQL Server,
everyone says need CIs for good perf?"
http://blog.sqlpositive.com/2011/06/diff-oracle-sql-server-inde
Not sure if i have time to study it today, but sure I will try to read it
thoroughly. If anyone insterested, please read and give your comments.
Denis

v*r2008-01-22 08:01

19 楼

Very good blog, but the blogger didn't actually answer the question he
raised:
"So how is it you can have good perf in Oracle, w/o IOTs, but in SQL Server,
everyone says need CIs for good perf?"
My answer is Oracle simply has more options to achieve the same that
SQLServer clustered-index could achieve.
Let's first think about what kind of table will benefit most from using
clustered-index/IOT. One typical example is table storing time series data
will benefit a lot. Using clustered-index/IOT on a table with time series
data, you can retrieve rows very fast by doing a range-scan on the indexed
columns, since rows are stored in the same order as index, there is no need
to sort and in the case of IOT, rows are retrieved at the same time while
reading the indexes.
But it will make inserts/updates more expensive. Even worse, you lost the
query flexibility, enforcing physical row order to table usually will only
favor the query using clustered-index column as the criteria at the expense
of slower performance when query criteria are change to other columns.
Oracle provides IOT when you are sure your table/application design will not
suffer too much by sacrificing the relational flexibility. But Oracle also
has one feature that provides performance benefit on querying time series
data without suffering relational flexibility, that is Partition, which
basically a logical grouping of data based on data value instead of
physically grouping data together based on one index ordering.

Server,

【在 y****9 的大作中提到】

: Just find an insteresting blog that seems addressing exactly same doubts:
: "So how is it you can have good perf in Oracle, w/o IOTs, but in SQL Server,
: everyone says need CIs for good perf?"
: http://blog.sqlpositive.com/2011/06/diff-oracle-sql-server-inde
: Not sure if i have time to study it today, but sure I will try to read it
: thoroughly. If anyone insterested, please read and give your comments.
: Denis

y*92008-01-22 08:01

20 楼

col
SSN,
in
Answer to myself: YES.
http://oracle-study-notes.blogspot.com/2011/09/sql-server-test-
It can imagine if we create a CI on a large table, we need free space and
temp db maybe to do the sorting.

【在 y****9 的大作中提到】

: If I have a one-million row table without any index, let's say it has a col
: called SSN and its values are unique. now i create a clustered index on SSN,
: what will happen to the existing table rows?
: For example, let's say each page can only hold two rows, at the begining,
: rows with ssn=1 and ssn=4 are in page no 1; rows with ssn=2 and ssn=3 are in
: page no 2. now i create a clustered index on ssn col, at the end will
: page no1 contains ssn=1,2 and page no 2 contains ssn= 3 and 4 ?

w*e2008-01-22 08:01

21 楼

对Oracle不熟, 就说说SQL Server吧.
1) 每个table最好有个CI, 是从两个主要方面来讲的:
a) Performance, b) storage (虽然storage现在不值俩钱, 但是我前段时间见到个
建了CI, storage减少了50%的--table level...)
2) PK 不一定就是CI. (但CI最好建在PK上)
至于怎么选择建CI, 咱们可以开另一个话题了.

y*92008-01-22 08:01

22 楼

Jonathan Lewis gives some good explainations why SQL Server prefers CI while
Oracle does not have to adopt it so widely.
http://www.simple-talk.com/sql/learn-sql-server/oracle-to-sql-s
Although I knew this series artical by JL for long time and have kept them
in my to read list, I only read the part 3 thoroughly till today. Thought it
is interesting for Oracle guy to know this difference.
Based on JL's test case, I fail to understand why CI will reduce storage as
compared to heap table, he shows the opposite.

【在 w*******e 的大作中提到】

: 对Oracle不熟, 就说说SQL Server吧.
: 1) 每个table最好有个CI, 是从两个主要方面来讲的:
: a) Performance, b) storage (虽然storage现在不值俩钱, 但是我前段时间见到个
: 建了CI, storage减少了50%的--table level...)
: 2) PK 不一定就是CI. (但CI最好建在PK上)
: 至于怎么选择建CI, 咱们可以开另一个话题了.

v*r2008-01-22 08:01

23 楼

如果 SQLServer 预设一个proper initial fill factor （like 70% or 80%) , I
doubt it is going to make any difference.
像 abusing CI 这种明显 violate relational theory 的东东，能成为 SQLServer 的
well accepted best practice, there is something seriously wrong with the
implementation of heap table in SQLServer.

while
it
as

【在 y****9 的大作中提到】

: Jonathan Lewis gives some good explainations why SQL Server prefers CI while
: Oracle does not have to adopt it so widely.
: http://www.simple-talk.com/sql/learn-sql-server/oracle-to-sql-s
: Although I knew this series artical by JL for long time and have kept them
: in my to read list, I only read the part 3 thoroughly till today. Thought it
: is interesting for Oracle guy to know this difference.
: Based on JL's test case, I fail to understand why CI will reduce storage as
: compared to heap table, he shows the opposite.

y*92008-01-22 08:01

24 楼

Can you elaborate a little bit about why CI violate relational theory?
CI seems dealing with how rows are organized in a table, while relational
theory seems dealing with how columns (attributes) of a table should be
releated. This is my understanding, could be wrong. Not good at theory and
never did database design :-(

【在 v*****r 的大作中提到】

: 如果 SQLServer 预设一个proper initial fill factor （like 70% or 80%) , I
: doubt it is going to make any difference.
: 像 abusing CI 这种明显 violate relational theory 的东东，能成为 SQLServer 的
: well accepted best practice, there is something seriously wrong with the
: implementation of heap table in SQLServer.
:
: while
: it
: as

v*r2008-01-22 08:01

25 楼

Here are my understanding for discussion ;-)
Being relational basically means manipulating data in sets. A set is
orderless, which is typically implemented as heap table in rdbms.
In relational theory, the moment you enforcing ordering to data sets, you
are out of relational domain.
Oracle IOT or SQLServer CI are all non-relational features in rdbms to deal
with performance for specific scenarios. Given a well implemented heap table
, non-relational features should only applies to specific scenario instead
of being a general best practice for all scenarios, which is the case in
Oracle.
When a non-relational feature like CI is recommended for every table in
SQLServer, there is something seriously wrong with its heap table
implementation. Jonathan's study case shows it could be due to SQLServer's
default 100% page/block filling. I doubt it is the only reason, otherwise it
would be easy to address instead of still promoting this BS best practice.

【在 y****9 的大作中提到】

: Can you elaborate a little bit about why CI violate relational theory?
: CI seems dealing with how rows are organized in a table, while relational
: theory seems dealing with how columns (attributes) of a table should be
: releated. This is my understanding, could be wrong. Not good at theory and
: never did database design :-(

y*92008-01-22 08:01

26 楼

I got your point. But my argument is as follows:
Relational theory does not require the enforcement of order in a set;
however, it does not mean the moment I enforce the order, I will lose all
the benefits/feature of relational data model. I still believe relational
theory or data model is about the relationship among attributes of an entity
. Being CI or IOT won't change the relationship of attributes, thus they are
still .... So I am OK with CI in SQL server, it is just a design choice,
maybe not smart, but OK.
Just my 2 cents.

deal
table

【在 v*****r 的大作中提到】

: Here are my understanding for discussion ;-)
: Being relational basically means manipulating data in sets. A set is
: orderless, which is typically implemented as heap table in rdbms.
: In relational theory, the moment you enforcing ordering to data sets, you
: are out of relational domain.
: Oracle IOT or SQLServer CI are all non-relational features in rdbms to deal
: with performance for specific scenarios. Given a well implemented heap table
: , non-relational features should only applies to specific scenario instead
: of being a general best practice for all scenarios, which is the case in
: Oracle.

v*r2008-01-22 08:01

27 楼

The moment you enforce order, you lose the thing called "relation" and the
flexibility of being relational. One benefit of such flexibility is the
ability for SQL engine optimizer to transform/rewrite your query based on
the grows/updates of your tables especially in complicated SQL query to try
to adapt the plan to achieve best performance. Those transform/rewrite are
based on relational mathematical model which deals with relation (orderless
datasets).
Same in SQL, the moment the order by is applied, the query is out of
relational layer of rdbms engine (where the relational math works), but in
SQL, if you find the order by is applied in wrong place (like too earlier in
query), it is easy to re-write it.
But when you make IOT/CI a best practice in the design of all your tables,
how are you going to address it without tearing down the table structure
when you realize the data access path changes as time goes on.
Besides, IOT/CI implies high cost for update/delete by nature. The question
is why SQLServer still recommends CI for all tables even it implies high
cost in many cases and suffer losing the relational nature of dataset. The
only explanation is their heap table implementation is so bad in performance.
I guess that is why Jonathan is trying to looking into this in his study but
he is polite enough to not saying abusing CI in any rdbms database is BS,
which is obviously is in my opinion.

entity
are

【在 y****9 的大作中提到】

: I got your point. But my argument is as follows:
: Relational theory does not require the enforcement of order in a set;
: however, it does not mean the moment I enforce the order, I will lose all
: the benefits/feature of relational data model. I still believe relational
: theory or data model is about the relationship among attributes of an entity
: . Being CI or IOT won't change the relationship of attributes, thus they are
: still .... So I am OK with CI in SQL server, it is just a design choice,
: maybe not smart, but OK.
: Just my 2 cents.
: