欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

 項目組會(huì )議上討論的關(guān)于不定字段數目的數據庫表問(wèn)題并沒(méi)有結果，今天繼續分析之后發(fā)現問(wèn)題可能還更大。當時(shí)討論的結果是可能采用四種技術(shù)：

• 動(dòng)態(tài)增加數據庫表字段
• 預留足夠的空白字段，運行時(shí)作動(dòng)態(tài)影射
• 用xml格式保存在單字段里
• 改列為行，用另外一個(gè)表存放定制字段

【一】

現在我們來(lái)分析一下四種技術(shù)的優(yōu)劣，不過(guò)首先可以排除的是第一點(diǎn)動(dòng)態(tài)增加字段的方法，因為在實(shí)際操作時(shí)候幾乎是不可能的（sqlserver太慢，oracle索性不支持），基本可以不討論就排除。剩下后三點(diǎn)。

【二】

先來(lái)討論預留空白字段的方法，基本原理就是在數據庫表設計的時(shí)候加入一些多余的字段，看下面的代碼：

CREATE TABLE Sample(
  name varchar(12),
  field0 varchar(1),
  field1 varchar(1),
  fieldN varchar(1)
}

然后看實(shí)際運行時(shí)候的需要，動(dòng)態(tài)分配字段給系統使用，也許需要一個(gè)這樣的結構來(lái)描述分配情況：

public class Available
{
  public int CurrentUnusedFieldNumber;
  public Hashtable FieldToRealName;
}

也許某一時(shí)刻的數據狀況是這樣的： CurrentUnusedFieldNumber=3,哈西表FieldToRealName包含內容是("field0"="SomeId", "field1"="AnyName","field2=IsOk")
現在的問(wèn)題是如果要配合Hibernate，如何來(lái)處理？以上段的數據使用狀況為例子，如果我們的類(lèi)定義是這樣：
public class Entity01
{
  public string Name;
  public string SomeId;
  public string AnyName;
  public bool IsOk;
}

也許只需要修改一下xxx.hbm.xml，把 SomeId 和 field0做成對應就ok了。但是在運行時(shí)我們怎么知道會(huì )有這樣的類(lèi)定義？除非我們做動(dòng)態(tài)代碼生成，自動(dòng)編譯也許可以，但是問(wèn)題也許就到其他方面去了；如果我們不用動(dòng)態(tài)定義，那么類(lèi)就只能是這樣：
public class Entity01
{
  public string Name;
  public Hashtable ExtraFieldAndValues;
}


使用的時(shí)候，用 entity01.ExtraFieldAndValues.setValue("AnyName", "boss")的方式來(lái)引用，也許這樣是修改最少的了，但是問(wèn)題是Hibernate不支持這樣的方法。

【三】
再來(lái)討論單字段存儲的方法，我們使用這樣的數據庫表定義
CREATE TABLE Sample
(
  Name varchar(12),
  Xml CLOB(102400) // 僅作說(shuō)明而已
)


然后對應這樣的類(lèi)定義
public class Entity01
{
  public string Name;
  public string Xml;
  public Hashtable ExtraNameAndValueFromXml;
}


我們的代碼就可以這樣使用：string id =entity01.ExtraNameAndValueFromXml.getValue("SomeId")了。這樣解決看起來(lái)很不錯，不僅不需要Available表，而且看起來(lái)Hibernate對它的支持也很完美，但是致命的問(wèn)題在于：如果保持高效的查詢(xún)？除非數據庫系統本身對此有支持，否則就只能用低效的substring或者like做查詢(xún)，這在大批量數據中根本就不可行。
是不是折衷一下，把兩種方法的優(yōu)點(diǎn)和起來(lái)？問(wèn)題有來(lái)了：怎么保持兩者之間數據的同步？難道要我們用存儲過(guò)程去解析xml內容？
所以，一個(gè)兩難的問(wèn)題，需要我們認真去解決。我們通過(guò)認真的需求分析，也許可以減少可變字段的數量，但是只要有一個(gè)可變字段或者可變的可能性存在，我們始終要去解決這個(gè)兩難的問(wèn)題。
期待繼續討論。

【四】
還有一種方法就是改列為行，用另外一個(gè)表存放擴展字段，定義可以如下：
CREATETABLE SampleFields
(
  idSample Integer,
  fieldName varchar(30),
  fieldValue varchar(100)
)
其中idSample關(guān)聯(lián)到Sample表的id字段（我沒(méi)有寫(xiě)出來(lái)）。這樣的話(huà)，Hibernate很容易支持，也可以支持Sql的查詢(xún)，而且可以支持把內容放到Hashtable中去，看起來(lái)是目前最好的方式了。但是在大容量數據的時(shí)候，SampleFields表的數據會(huì )是主表數據量的N倍（看定制的字段數目多少而定），同樣存在有很?chē)乐氐男阅軉?wèn)題。


哪位高人還能再給一個(gè)方案？

--------2005-7-22新增-----------
很多朋友給出了很好的建議，其中蛙蛙池塘 給出了一個(gè)表結構，因為看起來(lái)不甚方便，我把類(lèi)圖畫(huà)出來(lái)如下：

CREATE TABLE [dbo].[ProductAttributeDataTypes] (
[DataTypeId] [int] NOT NULL ,
[Description] [varchar] (30) COLLATE SQL_Latin1_General_CP1_CI_ASNOT NULL 
) 

CREATE TABLE [dbo].[ProductAttributeListItems] (
[LookupListId] [int] NOT NULL ,
[ListItemId] [int] IDENTITY (1, 1) NOT NULL ,
[DisplayName] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_ASNOT NULL 
)
CREATE TABLE [dbo].[ProductAttributeLookupLists] (
[LookupListId] [int] IDENTITY (1, 1) NOT NULL ,
[Name] [varchar] (80) COLLATE SQL_Latin1_General_CP1_CI_AS NOTNULL 
) 
CREATE TABLE [dbo].[ProductAttributeTemplateCategories] (
[PATCategoryId] [int] IDENTITY (1, 1) NOT NULL ,
[Name] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[DisplayName] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_ASNOT NULL 
)
CREATE TABLE [dbo].[ProductAttributeTemplates] (
[AttributeTemplateId] [int] IDENTITY (1, 1) NOT NULL ,
[Name] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
[DataType] [int] NOT NULL ,
[LookupListId] [int] NULL ,
[PATCategoryId] [int] NOT NULL ,
[CustomerHelp] [varchar] (4000) COLLATESQL_Latin1_General_CP1_CI_AS NULL ,
[DisplayName] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_ASNULL 
) 
CREATE TABLE [dbo].[ProductAttributeValues] (
[ProductId] [int] NOT NULL ,
[AttributeTemplateId] [int] NOT NULL ,
[valueInt] [int] NULL ,
[valueStr] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_ASNULL ,
[valueMemo] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[valueBool] [bit] NULL 
)
CREATE TABLE [dbo].[ProductListItems] (
[ProductListId] [int] NOT NULL ,
[ProductId] [int] NOT NULL ,
[ItemDescription] [varchar] (80) COLLATESQL_Latin1_General_CP1_CI_AS NULL ,
[DisplaySequence] [int] NOT NULL 
)

不知道大家有沒(méi)有看懂這些表之間的關(guān)系,這是一個(gè)產(chǎn)品目錄的表,產(chǎn)品有不確定的屬性,每個(gè)屬性對應的數據類(lèi)型也不一樣,而且有的是用下拉列表選擇的,有的是是或否,有的是一段兒文字,這里用的就是數據模板來(lái)做的,這是里的一部分數據庫

以前有這樣的一個(gè)需求,不考慮像京東或者淘寶這樣分類(lèi)下有子分類(lèi)的情況,只考慮一層分類(lèi)的情況下,可以隨便添加分類(lèi),可以任意給商品添加屬性,而不需要更改表的結構.于是設計了一個(gè)這樣的結構,實(shí)現還是可以實(shí)現,一直在用,但是在操作上比較麻煩,大家討論下有沒(méi)有更好的方式. 

-----------------------------以下是幾個(gè)關(guān)聯(lián)的對象 省去了 getter/setter 方法------------------ 
Field.java屬性 

Java代碼

• public class Field{  
•    private Integerid;  
•    private Stringname; //屬性名稱(chēng)
  
• }  

Java代碼

• public class ProductField{  
•      private Integerid;  
•      private Fieldfield; //屬性對象
  
•       private Stringvalue; //屬性值 這里的值不管是整數 小數 還是什么類(lèi)型都是用 String 類(lèi)型
  
• } 

Java代碼

• public class Product{  
•    private Integerid;  
•    private Stringname; //商品名稱(chēng)
  
•    //根據商品加載這個(gè)商品的所有屬性 和屬性值
  
•    private SetproductFields = new HashSet();//商品屬性集合
  
• }  

Java代碼

• public class Type{  
•    private Integerid;  
•    private Stringname; //分類(lèi)名稱(chēng)
  
•    //通過(guò)類(lèi)型可以加載這個(gè)類(lèi)型下的所有商品  一種類(lèi)型對應多種商品
  
•    //(暫時(shí)不考慮一種商品屬于多種類(lèi)型例如手機屬于電器類(lèi),也屬于通訊類(lèi)產(chǎn)品)
  
•    private Setproducts = new HashSet();  
• }  

• +++++++++ 商品信息++++++++  
• Name:Sony  
• 價(jià)格 - 2000.00
  
• 型號 - YY-1939
  
• 名稱(chēng) -鎖你牌手機  

復雜商品的分類(lèi)，類(lèi)似淘寶的分類(lèi) 
1.每類(lèi)商品有無(wú)限級分類(lèi) 
2.每個(gè)商品可能會(huì )有交叉分類(lèi) 
3.每類(lèi)商品的擴展屬性不一樣 
比如： 
夾克的擴展屬性為 
款式： 拉鏈夾克 風(fēng)格： 休閑 品牌： other/其它 適合季節： 春秋 尺碼： M L 顏色： 其它顏色 質(zhì)地：純棉 
主板的擴展屬性為 
品牌： 微星/MSI 類(lèi)型： Socket478 芯片組： Intel 845 平臺類(lèi)型： Intel平臺 寶貝成色：8成新 

這些擴展屬性都會(huì )動(dòng)態(tài)的變化 

那么問(wèn)題來(lái)了： 
1.全文搜索如何合理建立？ 
2.可能后臺擴展屬性表是否需要動(dòng)態(tài)建立？ 
3.如果單件商品屬于交叉分類(lèi)的話(huà)，查詢(xún)結果記錄重復是否需要？ 
4.高效的無(wú)限級分類(lèi)算法大家可否指點(diǎn)一二，這個(gè)困惑了我很久了？ 

不求完整解決，給個(gè)思路也成

每個(gè)商品都是一個(gè)xml文件每個(gè)xml文件有一個(gè)ID 每個(gè)xml文件可以采用這樣的結構 
 
<名稱(chēng)/> 
<屬性/> 
<屬性/> 
...... 
 

當檢索商品的時(shí)候 比如用Socket478芯片組檢索 就檢索出所有含有Socket478芯片組屬性節點(diǎn)的xml文件.用一個(gè)xql語(yǔ)句就可以搞定. 返回的結果是xml文件 可以用xsl進(jìn)行處理然后用css顯示


這類(lèi)問(wèn)題（無(wú)限級別分類(lèi)，可以交叉分類(lèi)）很難。
正是現代 tag，分類(lèi)時(shí)代的熱點(diǎn)問(wèn)題。我也考慮調查了很久。
如果解決得好，就可以被收購了。

xml 解決起來(lái)確實(shí)比 relation table 容易一些。xml全文檢索也比較容易做。
我想，winterwolf會(huì )跳出來(lái)，終于等到了。

不過(guò)，xml也有一些限制。如果能有一種專(zhuān)門(mén)描述這類(lèi)問(wèn)題的數據結構就好了。
我想到過(guò)幾種數據結構。不過(guò)都沒(méi)有想透。
Multiple Key Hashmap。多維數組。等。
xml確實(shí)是一種解決的辦法，tianxinet的子表方法有點(diǎn)繁瑣了，擴展屬性有很多表也帶來(lái)了維護的困難性了。。如果像淘寶的商品分類(lèi)那樣的話(huà)，你的子表數量是很驚人的。。。。 
繼續關(guān)注中

前幾天有人問(wèn)了我一個(gè)這樣的問(wèn)題，因為時(shí)間的關(guān)系，我當時(shí)嘗試做了幾種回答，比如將產(chǎn)品先分大類(lèi)，為每個(gè)大類(lèi)設計一個(gè)產(chǎn)品表，在產(chǎn)品表中包括該類(lèi)的基本屬性，并預留一些字段作為擴展屬性，對于同一大類(lèi)不同的產(chǎn)品，考慮增加擴展表。不過(guò)這個(gè)答案似乎沒(méi)有得到認可。認真一想也是，如果這樣，表改有多少，查詢(xún)結構又該多復雜。
      電子商務(wù)，尤其是B2B和B2C的電子商務(wù)平臺，有著(zhù)自己的特殊情況的。首先，它的產(chǎn)品及其廣泛，差不多就涵蓋了世間所有可以出售的商品，其次，每種商品的屬性共性也不太可能分析和抽取。
      今天在網(wǎng)上發(fā)現一個(gè)網(wǎng)友的blog(http://hi.baidu.com/ifos/blog/item/5cf3de1f03dd7b67f724e4ea.html)，他提出了四種設計思路，
beyond_dream  寫(xiě)道
方案一。

就一個(gè)產(chǎn)品表product，然后這個(gè)表里包括所有的產(chǎn)品屬性，每個(gè)屬性用一個(gè)字段表示。

方案二。

還是只用一個(gè)產(chǎn)品表product 。
與方案一不同的是，私有屬性設置為一個(gè)字段Private_Attribute ，
然后每個(gè)產(chǎn)品的多個(gè)私有屬性都放這個(gè)字段里，并且用一個(gè)分隔符號隔開(kāi)
比如書(shū)籍，就是它在 Private_Attribute 字段里 的表示就是 ：

出版社||||作者||||出版日期

方案三；

產(chǎn)品表+ 私有屬性表 + 私有屬性值 表
產(chǎn)品表里 就包括一些產(chǎn)品的公共屬性
私有屬性表里 設置私有屬性的名稱(chēng) ，比如出版社 、作者 、出版日期
私有屬性值表 里就是 每個(gè)產(chǎn)品 私有屬性的值

例如：
產(chǎn)品表： 
product_id= 1 ; product_name =《ajax實(shí)踐》
私有屬性表：
Attribute_id= 1 ; Attribute_name = 出版社
Attribute_id= 2 ; Attribute_name = 作者

私有屬性值表:
id =1 ; product_id = 1 ; Attribute_id = 1 ; Attribute_value =清華出版社
id =2 ; product_id = 1 ; Attribute_id = 2 ; Attribute_value =老外

方案四；

每個(gè)不同類(lèi)型的產(chǎn)品單獨設計一個(gè)數據庫，比如一個(gè)書(shū)籍的數據表product_book，一個(gè)MP3的數據表 product_mp3

        看了一下，突然萌生出一些想法來(lái)，愿與大家交流討論。
      首先想的是，電子商務(wù)產(chǎn)品表設計的最佳是由哪些因素決定的。個(gè)人認為，主要包括高效率的查詢(xún)性能以及可易擴展的設計。我們于是從這兩個(gè)方面分析上述四種設計，第一種方案幾乎沒(méi)有可擴展性（列的擴展遠遠不夠于包含所有產(chǎn)品不同的屬性）；第二個(gè)方案看上去可擴展性不錯，不過(guò)它的屬性就全部以純文本的樣式存儲，查詢(xún)效率自然想到差；第三種方案看上去是一個(gè)折中，實(shí)際上它是產(chǎn)品、屬性、屬性值的笛卡爾積了，數據量將非常巨大，根本不適合大型的電子商務(wù)平臺，因為查詢(xún)效率會(huì )很低，并且對于結果的拼排將是很大的代銷(xiāo)；第四種方案也許擁有最好的擴展性，但是如果對于跨產(chǎn)品的查詢(xún)，也將是低效率的。
      這么看來(lái)，這將是個(gè)NP了。而實(shí)際上呢？阿里巴巴做得很好。我不知道阿里巴巴是如何做到的，但是在仔細看了阿里巴巴的網(wǎng)站后，個(gè)人覺(jué)得有些東西其實(shí)妨礙了我們的思路。
        列下幾個(gè)問(wèn)題，可供大家思考：
    1. 是不是產(chǎn)品的所有可能屬性都屬于查詢(xún)條件？ 看看阿里巴巴，它的查詢(xún)條件涵蓋所有屬性了么？
    2.是不是所有屬性都是具有獨立性的存在的?換句話(huà)說(shuō)，如果一個(gè)物品有幾百上千種可列屬性，是否我們需要將它每一個(gè)屬性作為單獨存在的屬性來(lái)描述？
    3.除了傳統的數據庫的SQL查詢(xún)，我們又是否可以借助某些數據庫的特性或者說(shuō)其他的查詢(xún)技術(shù)呢？（比如XPATH）。
    4.客戶(hù)只輸入了一個(gè)模糊條件，是不是就一定意味著(zhù)需要在所有的產(chǎn)品信息中查詢(xún)呢？（是否可以識別用戶(hù)習慣，是否又可以像傳統搜索引擎一樣進(jìn)行關(guān)鍵字排行呢？）
    5. 用戶(hù)輸入的關(guān)鍵字查詢(xún)，又是不是對產(chǎn)品的所有屬性有效呢？還是只是涵蓋了產(chǎn)品的關(guān)鍵屬性？
    6. 客戶(hù)的查詢(xún)真的是像傳統信息系統一樣知道精確的所有結果么？還是只想知道最佳的結果？
      其實(shí)有興趣的朋友，可以上淘寶、上阿里巴巴，看一看，也就可以給這幾個(gè)問(wèn)題列出答案了。

      好了，雖然我不是電子商務(wù)行業(yè)，也沒(méi)有真實(shí)面對過(guò)這類(lèi)問(wèn)題，談到這里，就大概說(shuō)一下我對電子商務(wù)平臺產(chǎn)品物流模型設計的思路吧，有興趣的朋友可以參考驗證一下，也可以交流一下。
1.對產(chǎn)品按照大類(lèi)進(jìn)行區分，每個(gè)大類(lèi)有一個(gè)產(chǎn)品表。產(chǎn)品表有該大類(lèi)產(chǎn)品最基本的關(guān)鍵屬性信息（應該控制在十個(gè)以?xún)?，這些屬性，也被用作關(guān)鍵字查詢(xún)索引），而接下來(lái)，又有一些預定義的擴展屬性（命名如customized1,customized2，等等），這些擴展屬性有一個(gè)重要的前提，就是它們的屬性值都是列表選擇的，而不是自由輸入的（當然這些選擇項是可以在另外的表中定義的），這些屬性是用作在詳細的高級查詢(xún)中使用的，使用選擇而不是自由輸入第一是可以提高索引效率，第二是可以避免因為字符差錯引起的歧義，第三是可以使用區間值。每個(gè)不同的產(chǎn)品小類(lèi)有不同的customized定義。最后有再有幾個(gè)字段，則存放其他的由客戶(hù)特性帶來(lái)的屬性值，但是是以xml的形式存放，可以方便使用XPATH來(lái)提升效率。
      當用戶(hù)在統一的文本框輸入模糊查詢(xún)條件時(shí)，可以通過(guò)事先建立的關(guān)鍵字索引或者優(yōu)先排名或者用戶(hù)習慣來(lái)確定首先尋找的產(chǎn)品大類(lèi)范圍。這樣就將查詢(xún)首先限制在幾個(gè)主要的產(chǎn)品中。然后通過(guò)基本的屬性進(jìn)行基于SQL的比較查詢(xún)。同時(shí)列出查詢(xún)結果所對應的產(chǎn)品小類(lèi)。用戶(hù)可以進(jìn)入產(chǎn)品小類(lèi)進(jìn)行更詳細的查詢(xún)，這個(gè)時(shí)候的查詢(xún)就包括了由customized字段定義的一些區間值或者選項值。用戶(hù)同時(shí)又可以輸入一些特別的條件（在這個(gè)區間外，也許某類(lèi)產(chǎn)品本身的特性，如同pconline上不同產(chǎn)品的詳細特性），這個(gè)時(shí)候就可以運用XML技術(shù)來(lái)進(jìn)行最后一些字段的過(guò)濾與篩選了。
    其實(shí)整個(gè)這個(gè)設計思路是在確?？蛻?hù)的查詢(xún)有效性、響應時(shí)間及數據庫性能及結構的可擴展性上進(jìn)行了一些折中和考慮，在不損失表結構的可擴展性上，既保證了每張表的表空間不會(huì )過(guò)大，也同時(shí)保證了查詢(xún)的最優(yōu)有效性。它其實(shí)還需要借助其他的一些技術(shù)，比如搜索關(guān)鍵字識別及優(yōu)化、結果排名、用戶(hù)習慣及模糊行為分析、基于XML的查詢(xún)等。
    蠻想聽(tīng)聽(tīng)來(lái)自互聯(lián)網(wǎng)電子商務(wù)行業(yè)的朋友的一些想法，歡迎交流討論。

http://raylinn.javaeye.com/admin/blogs/260407 

ms和我以前想的這個(gè)有點(diǎn)像。。。 固定的屬性和模糊的介紹都通過(guò)lunce來(lái)搜索。。




問(wèn)題補充
我也是想用多個(gè)表，多個(gè)表有點(diǎn)不好的地方，就是如果用戶(hù)在A(yíng)表買(mǎi)了一件產(chǎn)品，又在B表買(mǎi)了一件產(chǎn)品，那么到最后統計用戶(hù)買(mǎi)過(guò)的產(chǎn)品時(shí)，雖然可以從下訂單那個(gè)表讀出來(lái)，但是感覺(jué)有點(diǎn)亂~~~
問(wèn)題補充：
產(chǎn)品類(lèi)別表(類(lèi)別id,名稱(chēng),...) 
產(chǎn)品表(產(chǎn)品id,名稱(chēng),規格,...) 
產(chǎn)品屬性表(產(chǎn)品屬性id,產(chǎn)品id,屬性id,值,...) 

這種方法行不行？
問(wèn)題補充：
產(chǎn)品表(產(chǎn)品id,名稱(chēng),規格,...) 
產(chǎn)品屬性表(產(chǎn)品屬性id,產(chǎn)品id,屬性id,值,...) 

就說(shuō)這兩個(gè)表吧，當插入一件產(chǎn)品的時(shí)候，屬性應該是直接去到產(chǎn)品表的，如果加了一個(gè)屬性表，那么插入的時(shí)候， 
難道可以插入一個(gè)產(chǎn)品id在產(chǎn)品表，然后又插入屬性在產(chǎn)品屬性表嗎？

方案一（推薦）：在商品類(lèi)型已知的情況下，為每類(lèi)商品定制一個(gè)類(lèi)。class 手機，class筆記本 
方案二：如果商品類(lèi)型位置，那就用一個(gè)通用的商品類(lèi)，里面放個(gè)property