1. 怎樣用excel資料庫建立倉庫管理系統
倉庫管理系統，這個題目有點大。不同的單位其要求也不同的。
對工廠來說，有成品倉庫、半成品倉庫、原材料倉庫、廢品倉庫、暫借倉庫、到貨待檢倉庫、包裝材料倉庫等等。
倉庫管理的要求也不同，有的僅記錄倉庫進出，有的要將庫存同生產系統聯動，參與主生產計劃的運算或參與材料需求計劃的運算。
綜上所述，這個倉庫系統的建立首先要看需要這個系統解決什麼問題。
下面做一個最簡單的成品庫存管理，也可以用於貿易公司的進銷存。為了簡便，每天對於同一種產品的入庫或出庫僅記錄一個總入庫數或總出庫數。
共建立3張工作表，分別對應入庫、出庫、在庫。在月初對期初在庫進行更新，記錄保留一個月的入出庫數據。月末對賬後可以將這個數據文件保留便於查詢。同時將月末數據復制到下月的期初數據中。如下圖所示：
實際運用中可結合送貨單做自動出庫登錄等。
2. 產品資料庫的建立
你需要建立兩個表，一個是產品表，欄位有：
產品ID、產品名稱、出廠日期、……等欄位
另外一個是維修記錄表，欄位有、
維修記錄ID、產品ID、維修時間、維修人、維修價格、……等欄位
需要查詢某時間段的維修情況，可以使用下面的SQL語句：
SELECT * FROM 維修記錄 WHERE 維修時間 BETWEEN 開始時間 AND 結束時間
需要查詢某設備的維修情況，使用下面的SQL語句：
SELECT * FROM 維修記錄 WHERE 產品ID＝'產品ID'
上面的語句，如果需要查詢維修次數、金額，那麼語句的SELECT部分為：
SELECT COUNT(*),SUM(維修價格)
3. 建立購物網站資料庫 需要哪些表和欄位 越詳細越好
SQL SERVRE 2000 測試通過
CREATE DATABASE shop
GO
use shop
/* ************************** 用戶信息 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'UserInfo_table')
DROP TABLE UserInfo_table
GO
CREATE TABLE UserInfo_table
(
userId smallint /*用戶編號*/
IDENTITY(1,1),
loginName varchar(20) not null, /*登陸名稱*/
userName varchar(20) not null, /*用戶名稱*/
userPwd varchar(10) not null, /*用戶密碼*/
userType varchar(20) not null, /*用戶類型*/
userSex varchar(2), /*用戶性別*/
userPhone varchar(20), /*用戶電話*/
userEmail varchar(40), /*用戶郵件*/
userAddress varchar(200), /*用戶地址*/
userZip varchar(10), /*用戶郵編*/
createTime datetime default getdate(), /*注冊時間*/
updateTime datetime, /*更新時間*/
userStatus varchar(4) not null, /*用戶狀態*/
userLevel int, /*用戶級別*/
constraint pk_userinfo primary key(userId)
)
/* ************************** 系統代碼表 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'CommonCode_table')
DROP TABLE CommonCode_table
GO
CREATE TABLE CommonCode_table
(
codeType varchar(20) not null, /*代碼類型*/
codeName varchar(20) not null, /*代碼名稱*/
codeValue varchar(100) not null, /*代碼值*/
constraint pk_commoncode primary key(codeType, codeName)
)
/* ************************** 菜單信息 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'MenuShop_table')
DROP TABLE MenuShop_table
GO
CREATE TABLE MenuShop_table
(
menuId varchar(50) not null,
menuName varchar(50),
menuImg varchar(50),
menuSelImg varchar(50),
menuAction varchar(50),
menuLevel smallint not null,
parentMenuId varchar(50),
menuLine smallint not null,
isUserMenu bit not null,
constraint pk_menushop primary key(menuId)
)
/* ************************** 用戶訂單 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'UserOrder_table')
DROP TABLE UserOrder_table
GO
CREATE TABLE UserOrder_table
(
orderId varchar(50) not null, /*訂單號*/
userId smallint not null, /*訂購人ID*/
orderTime datetime not null, /*訂單產生日期*/
orderStatus char(2) not null, /*訂單是否確認,0/1*/
orderPassTime datetime, /*確認時間*/
orderPassId smallint, /*訂單處理人*/
orderSendState char(2), /*訂單發送狀態*/
orderRecName varchar(20), /*訂單接收人姓名*/
orderRecMail varchar(20),
orderRecAddress varchar(200), /*訂單接收地址*/
orderRecZip varchar(10), /*訂單接受地址郵編*/
orderTotalPrice decimal(10,2), /*訂單總價*/
lineIndexNext int,
constraint pk_userorder primary key(orderId)
)
/* ************************** 訂單中項目信息 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'LineItem_table')
DROP TABLE LineItem_table
GO
CREATE TABLE LineItem_table
(
orderId varchar(50) not null, /*訂單號*/
lineIndex int not null, /*訂單索引*/
itemId varchar(50) not null,
proctId int not null, /*產品ID*/
quantity int not null, /*訂單項數量*/
unitPrice decimal(10, 2) not null, /*該訂單項的價格*/
orderStatus int not null,
constraint pk_lineitem primary key(orderId, lineIndex)
)
/* ************************** 商品類別信息 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'ProctCategory_table')
DROP TABLE ProctCategory_table
GO
CREATE TABLE ProctCategory_table
(
catId int
IDENTITY(1,1), /*類別編號*/
catName varchar(100) not null, /*類別名稱*/
parentId int, /*父級類別ID*/
catHaveChild varchar(2) not null, /*是否有子類別Y/N*/
sort int not null, /*排序標志*/
inputdate datetime default getdate(), /*建立時間*/
isValid varchar(2), /*此類別是否有效*/
decs varchar(255), /*說明*/
constraint pk_proctcategory primary key(catId)
)
/* ************************** 產品信息 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'ProctInfo_table')
DROP TABLE ProctInfo_table
GO
CREATE TABLE ProctInfo_table
(
proctId int
IDENTITY(1,1), /*編號*/
catId int not null, /*類別ID*/
proctName varchar(100), /*物品名稱*/
proctContent varchar(4000),
proctDesc varchar(1000), /*物品簡介*/
isPrompt bit default 0, /*是否優惠*/
registerTime datetime default getdate(), /*上架日期*/
listPrice decimal(10, 2), /*物品價格*/
unitPrice decimal(10, 2), /*會員價格*/
orderDesc varchar(1000), /*訂購說明*/
proctImgUrl varchar(200), /*物品圖片*/
sort int, /*排序標記*/
proctCount int, /*庫存量*/
isValid bit not null,
constraint pk_proctInfo primary key(proctId),
constraint fk_proct foreign key(catId)
references ProctCategory_table(catId)
)
/* ***************************************************************************** */
create index ProctCategory on ProctInfo_table(catId);
create index ProdcutName on ProctInfo_table(proctName);
/* ************************** 公告信息 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'BulletinInfo_table')
DROP TABLE BulletinInfo_table
GO
CREATE TABLE BulletinInfo_table
(
bulletinId int
IDENTITY(1,1), /*編號*/
bulletinTitle varchar(100) not null, /*公告板標題*/
bulletinBody varchar(4000), /*公告板內容*/
inputDate datetime default getdate(), /*添加日期*/
updateDate datetime, /*更新日期*/
inputUserId smallint, /*添加管理員ID*/
bulletinPoint int, /*瀏覽量*/
bulletinSort int, /*排序標記*/
isValid char(2) default 1, /*是否有效*/
constraint pk_bulletinInfo primary key(bulletinId)
)
/* ************************** 公告信息 ************************** */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'ItemInfo_table')
DROP TABLE ItemInfo_table
GO
CREATE TABLE ItemInfo_table
(
itemId varchar(50), /*項目ID*/
proctId int not null, /*項目產品ID*/
quantity int not null,
listPrice decimal(10,2), /*物品價格*/
unitPrice decimal(10,2), /*會員價格*/
status varchar(2), /*更新日期*/
constraint pk_iteminfo primary key(itemId)
)
/* ************************************************************* */
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'Serial_Number')
DROP TABLE Serial_Number
GO
CREATE TABLE Serial_Number
(
serialId varchar(50) not null,
SerialNumber int,
constraint pk_SerialNumber primary key(serialId)
)
4. 問一個關於ACCESS資料庫的問題
先要判斷到貨日期，用產品表做一個查詢，在查詢里一個空欄位里寫入：
IIF(到貨日期>=date(),'到貨',到貨日期)
這句語句是讓 到貨日期 欄位到了時間自動顯示到貨字樣，沒到貨日期不變。這樣你就可以隨時判斷 到貨日期 作出篩選，顯示為到貨的把他篩選出來：
Select * From [產品表 查詢] Where IIF(到貨日期>=date(),'到貨',到貨日期)='到貨'
再加個下單日期判斷也是一樣：
Select * From [產品表 查詢] Where IIF(下單日期>=date(),'已下單',下單日期)='已下單'
假設這個判斷下單的查詢叫 查詢1，判斷到貨的查詢叫查詢2
那就用這個查詢1去匹配訂單表,把這個查詢名稱取為查詢3和查詢4：
Select * From 訂單表 Inner join 查詢1 on 訂單表.訂單編號=查詢1.訂單編號;
匹配完了就是顯示想匹配的訂單表裡的欄位，你把他們全部更新一下：
Update From 查詢2 set 全部下單=1;
這里又說回去了，全部下單和全部到貨是根本的兩碼事，所以要建立四個查詢分開來做判斷；更新欄位也不能有起更新也要分開來更新。
所有的這一些語句，不要用表來做操作，你要用窗體事件來觸發：
比如一邊錄入數據一邊觸發，或者用宏來觸發，或者用有個控制項事件來觸發；
總結一下，我的思想是分兩個步驟：
1. 檢索出下單日期到期的行-----查找訂單可以更新的行------更新下單狀況
1. 檢索出到貨日期到期的行-----查找訂單可以更新的行------更新到貨狀況
你可以把語句全寫在有個事件過程，或者放在有個宏里一起執行。這就是你想要的結果
5. 獲取伺服器時間寫入資料庫
用不著這么麻煩
下面我給你兩種資料庫的時間函數
建立一個時間欄位~`
1.編輯Access資料庫表
時間欄位下面的默認值里寫"Now()"
2.編輯SQL資料庫表
時間欄位下面的默認值里寫"GetDate()"
這樣在添加一條記錄以後~`這個欄位里會自動填上添加的日期時間
補充回答:
資料庫放在伺服器上獲取得當然是伺服器時間
6. 如何建立物流中心
當今企業無一不關注成本的控制、運作的效率、服務的改善。這一切的基礎就是建立一個高效的物流體系。這是一個快速變革的時代對現代企業的要求，也是企業生死存亡的戰略依託之所在。價格戰的興行、呼聲日高的創新潮流，令中國企業必須更多地反思並完善自身的內部運作。Harold Pan集合其多年物流管理的經驗采寫的這篇精彩文章，對零售業這個對物流管理要求最高的行業進行了分析和總結，為中國經理人在建立和改善其物流管理方面提供了極為寶貴的借鑒經驗。 作者簡介：作者Harold Pan曾在美國Warner-Lambort在華合資企業任職多年，主管公司的采購及物流工作。 中國有句古諺雲：人盡其才，物盡其流。這很好地道出了快捷高效的物資流動對國計民生的重要性。目前，電子商務在中國踽跚而行，很大程度上也起因於中國現階段相對滯後發展的物流體系。物流，在昨天、今天和明天都將是你企業經營中一個不可或缺的重要環節。 在眾多行業中，無論是從貨物流動及相伴的信息流動的規模還是速度來講，零售業都是當之無愧的龍頭老大。零售業的物流成本在其總成本的構成中，高達20%以上。因此，物流戰略的正確制定和有效執行，是零售企業在市場競爭中勝出的一個決定性因素。全球著名的零售商，如沃爾瑪（Wal-Mart）、麥德龍（Metro），無一例外地藉助於卓越的物流管理，取得了令人側目的市場地位。我們相信，通過對零售業物流戰略的解剖，中國經理人能從中了解現代物流管理的真諦。 深入了解 零售行業在中國以至全球范圍內正在發生翻天覆地的變化。消費者前所未有的廣泛選擇機會使零售商們培感市場壓力重重。以美國為例，1985年盈利居前15位的零售企業，時至1995年，僅有6家還名列其中。在中國，零售商們的利潤率步步下滑，早已遍為人知。 在如此劇烈的市場競爭中，零售商必須嚴格控制其運行成本。這就要求你擁有一流的物流管理體系，使貨物能及時而經濟地到達最終消費者手中。舉沃爾瑪為例，它和Kmart（編者譯：凱馬特）經銷的商品結構頗為相近，但沃爾瑪的運行成本比凱馬特低25%。如此懸殊的差別從何而來？其中一個重要的起因，就是沃爾瑪得益於其先進的物流信息系統，使它能快速判別消費者的購買偏好，從而使商品的整體成本一減再減。據測算，沃爾瑪的單位面積銷售額竟然是凱馬特的兩倍。 其實，不僅僅只有連鎖零售企業注重物流管理。我們來觀察一下與之完全不同的行業，時裝零售商。歐洲的時裝商家往往在銷售旺季前，在遠東地區大規模低成本地批量生產。不難想像，有些款式會成為熱銷品而斷貨，而一些款式則可能滯銷而不得不打折清貨。為此，時裝商家們現在只在季前批量生產預計總銷量的60%到70%，然後再根據市場上的動銷情況，在歐洲組織剩餘部分的生產。這樣，盡管在歐洲生產熱銷款式的成本較高，但這樣做卻使部分款式供不應求，部分款式供過於求的現象大為減少，從而保證了總體的盈利水平。企業的高層主管在制定相應的物流戰略時，應該具體問題具體分析，針對企業的特定情況量身定做。他們必須對物流的方方面面有深入的了解，對物流在整體企業經營中所取的作用必須有清醒的認識。只有如此，方能作出明智的決策。 根本問題 不管零售商採用哪種物流戰略，都必須解決幾個最基本的問題： 首先，必須用整合的觀點來看待物流體系。物流體系涉及眾多部門，如計劃、采購、運輸以及銷售部門。各部門的目標各異，就很難做到勁往一處使。比方說，銷售部門通常根據銷售額、毛利等來確定最終獎勵。它們往往熱衷於發現熱銷商品，希望采購部門在進貨時拚命砍價，並盡量避免打折清貨。而計劃部門則往往注重保證貨物充沛、貨物周轉順暢，所以常況下只留意購物的批量和頻率。 然而，為了不超出采購預算，采購部門經常挑選最低價的同類商品，盡管這樣做往往意味著交貨期過長、庫存居高不下、倉儲成本上升，而拉升企業總體成本。預算方面的限制，又往往使得采購部門必須等到滯銷商品清倉處理後，才有可能再追訂熱銷產品。這樣，往往使熱銷商品庫存不足，而滯銷商品庫存過量。另外，采購預算方面的控制，往往使采購部門在期初拚命進貨，而期末則無事可做，因為此時采購額度已經花完。 為了克服物流過程中的種種障礙，企業上下的每個人，都要意識到自己的行為對企業總體的影響。其中的一種選擇就是將計劃部門、采購部門，甚至零售點統統捆綁在一起，評估他們作為一個整體的團隊績效。這樣，各個部門就能做到同舟共濟，在做相關決策時互相協調。在編制預算和成本時也能從整個物流鏈的角度出發加以考量。 當部門間的相互協作問題順利解決後，我們再轉向物流戰略的第二個問題：全程優化。通常，物流流程的局部優化往往造成整個物流環節的劣化。在這里最糟糕的情況是，單純強調配送中心的成本優化。對於大多數零售商而言，配送中心的運作與工廠類似：很好地體現了規模效應、自動化操作和工作效率。零售店相對而言則是個高成本運作的場所。但公司往往會不加思量，就將商品從配送中心向零售店轉移，結果使零售店庫存居高、運作成本上升。其實，公司往往可以考慮反其道而行之，將庫存從零售店移到配送中心。這樣的話，可以盡量減少在零售店中發生的商品處理費用。 一些在配送中心輕而易舉便能完成的作業，若想在零售店中完成可絕對不是件輕松的事。我們可以舉一個例子，熱銷商品應該在配送中心保持足量的庫存，並根據零售店的銷售情況整箱補貨：對一些價格昂貴、銷售較慢的貨品，則應該拆箱後分件向零售店補貨；對於另外一些佔地較多的拋貨或搬運費力的貨品，則應當盡量減少中間的處理環節，甚至可以直接從供貨商向零售店送貨。其目的是在於對供貨商到零售店的整個環節做到物流成本的最優化。企業萬不可將整個物流鏈加以肢解，只在局部環節實行優化了事。 物流戰略面臨的第三問題是預測。對相關信息的有效利用，會大大改進零售環節中的計劃職能，從而使零售企業的競爭能力大為提高，以高效率地在適當時間向合適的地點派送適量的商品。 絕大部分零售企業的庫存管理，與特定零售點和具體商品密不可分。但是，在特定的零售點上，具體到某一樣商品的銷量，前後波動是很大的。除少數暢銷品和促銷品外，消費者對大部分商品表現出的購買行為是難以捉摸的。但如果你將一個配送中心區域內所覆蓋的零售店作為一個整體來考慮，則商品的銷量要容易預測得多。所以，在預測銷量時，盡量在特定零售點上少費周折，將注意力集中在配送中心或整個公司的相關銷量上，由此而來的預測要可靠得多。 即使在時裝的零售方面，銷量預測工作亦是大有文章可做。一些經營精品時裝的商家用產品目錄來測試市場，而另外一些時裝商家會通過征詢一部分買者對於銷量的預測來備貨，還有的則通過向主要客戶播放季前的時裝表演，來獲取有關未來銷量的信息。當然再完善的預測方法也有其局限，重要的是要懂得如何應付不確定性。在高檔時裝領域，動銷較慢的款式必須在它們過時之前及時清倉處理，而銷路看好的款式必須及時發現、及時補訂。萬一補訂不再可能，有關這季什麼見好的信息，對於下季推出什麼流行款式也大有裨益。 歸根結底一句話，能夠預測的一定要預測好，不能預測的則一定要准備有效的應對手段。 零售業的一些佼佼者們，不但在上述三個方面做得無懈可擊，它們還根據自身的市場競爭戰略來構造自己的整個物流體系。我們在這里列舉了三種迥然不同的物流戰略，從中可以一窺成功的零售商品是如何制定其物流戰略的。 快速反應戰略 高檔時裝是此類物流戰略的代表。眾所周知，高檔時裝經營的風險巨大。欲領時尚風騷的廠商要迎合消費者的口味。它們既要用富有創意的設計去取悅顧客，同時也要保證新奇的設計轉化為市場上的賣點，因此在時裝設計、製造和營銷等各個環節都必須環環緊扣，以在這個充滿變化的行業里降低經營風險。 有的廠商利用郵購來探知顧客喜好，在進行試銷時考慮不同地區間顧客偏好上的差異。另外，先行上市地區的銷售情況也能提供預測數據。至此，時裝商家們還是都有章可循。 最能顯示出物流戰略力量的，莫過於能將那些為市場所認同的款式在過時之前，即刻放到零售店的貨架上。要做到這一點，有時依賴於與供貨商長期的融洽關系，有時則會要求你買斷供貨商的部分生產能力。與供貨商關系融洽，成衣從設計到上市的周期就會縮短，同時也能滿足數量上的要求。為了留有餘地，時裝商家一般會要求供貨商事先為其預留一定的生產能力。但不到最後時刻，它們一般不會貿然下達最終訂單。時裝在整個物流過程中都是只爭朝夕。零售商通常只對少數熱銷斷檔的款式願意空運。但高檔時裝商家往往在試銷時空運所有的熱銷款式。同時為了應付不虞之需，經常在一個中心倉庫存貨，並由此向各地空運或用公司的貨車送貨，運輸周期一般短於3天（請注意，這里所說的是歐美國家的情形）。達成如此的高速花費不菲，但隨後的銷量會彌補所產生的額外費用。整個物流戰略的中心，在這里便是盡量捕捉市場機會，哪怕意味著昂貴的運輸成本，也要盡快使商品到達零售店，以使銷售和利潤最大化。 物流體系在處理滯銷款式方面也大有作為。將實際銷量與預測銷量作一比照，很快便可辨識出滯銷款式。這樣，企業馬上就能採取降價等措施，以趕在銷售季節結束前清貨。在有些情況下，還能根據市場上的銷售情況，修改面料和輔料的相關訂單。 持續補貨戰略 並不是所有零售商面對的市場都象時裝那樣瞬息萬變。對於這些零售商來說，顧客需求相對比較容易預測，所以它們只需保證在貨物出現斷檔前及時補貨，便能滿足顧客的購買需求。 幾個美國的連鎖集團從事休閑服裝的銷售，其中一些商家獲利豐厚，因為在消費者看來，它們貨架上的衣物時刻散發著一種新鮮感。其實做法也頗為簡單，就是保證貨架上待銷的衣物，有充足的顏色、尺碼和款式搭配。高檔時裝的顧客可能願意等幾天，讓所需的款式從別處運來。與此不同，休閑裝的顧客一看中意的款式沒貨，可能就立馬離去。要滿足這一部分顧客的需要，必須有一個高度專業化和高效率的物流體系。 大牌零售商往往一年推出幾波款式，交貨期也比較長，因為大多為海外製造以求低成本。另外，休閑服裝售價上的限制也決定了不能採用空運方式。這樣一來，漫長的運輸時間更延長了整個的交貨周期。在這里，物流戰略的著眼點並非速度，而是穩定持續的物流。從工廠到商店再到購買者手中周而復始，不能出現斷檔。 休閑服在離開製造廠時，往往就能標明最終的零售店，之所以在配送中心中轉無非求個轉載方便。每個商店根據以往的出貨記錄，都定下一個相對穩定的送貨款式組合。銷售情況被密切監控，一旦確定滯銷品便不加猶豫地打折處理。 但是固定的款式組合，也不一定能與該商店整年的需求相匹配。所以，花色、尺碼和款式上的需求波動又要求零售商在此具備一定的靈活度。與零售店地理位置相近的區域中心倉庫，能保留足夠的緩沖庫存來應付零售店的需求波動，同時又能保證及時經濟的補貨服務。通常一周三次的補貨就足以滿足零售店的日常需求。 低成本戰略 使物流成本保持低位，是象沃爾瑪這種廉價商品零售商的看家本領。沃爾瑪在設置新點時，往往以其現有配送中心為出發點。沃爾瑪的賣場一般都設在配送中心周圍，以縮短送貨時間、降低送貨成本。除此以外，沃爾瑪等零售業巨子在物流管理方面，還有一些使人耳目一新的做法。 其中一個被日益廣泛採用的策略，就是由供貨商來負責相關商品的庫存和物流管理。供貨商通過零售商提供的銷售信息，能十分高效地排定自己的生產計劃和送貨計劃。這樣，雙方都能降低庫存成本。在某些情況下，零售商索性讓生產商來負責相關商品的物流管理。比方說，有些小百貨商品一般在零售店和配送中心都沒有庫存，製造商要得到相關的業務，就必須在特定的托盤上按照零售商的要求，裝上特定品種和數量的貨物，在指定時間送到配送中心，使配送中心的送貨車能便捷地將它們裝運到所指定的零售店。這樣，就免除了拆箱再拼裝等中間步驟，能降低倉儲成本。對於一些在促銷活動前就必須就位的促銷品，包裝箱上都作了標記並被存放在特定的區域，這就能盡量減少不必要的處理環節。在促銷開始時，這些促銷品就能整批按時送達促銷現場。這種做法，能使零售店的工作人員從繁重的商品分類標識活動中解脫出來，而專注於顧客服務。這類物流戰略，最大限度地祛除了從零售店反推到供貨商整個物流環節中可能發生的費用，其目的是盡量降低商品的售價。 各取所需 當然對各路零售商家們來說，還有其它經營戰略，我們在此也不可能一一詳述。不同的經營戰略，必須輔之以不同的物流戰略。在此，一個低檔時裝零售商的物流戰略值得一提。該零售商同樣通過試銷來預測銷量，同樣使用一個配送中心來應付需求方面的波動。與眾不同之處在於，只有在它目睹什麼款式在高檔時裝店裡熱銷時，才確定最終訂單。它在判斷時尚趨勢方面並無過人之處。但一旦有熱門款式露頭，它就會迅速通過位於海外的一些廉價供貨商大量製造。如此物流體系的最終結果，就是實現了其低價位大眾化時裝經營戰略。 建立一套完備的物流體系，需要在資金人力方面做大規模的投入。相關公司在管理一個復雜多變的系統方面，必須擁有豐富的專業知識。一個處處適用的物流體系是不存在的。你所能做到的，就是根據你的經營戰略，根據你有別於競爭對手的產品和服務，來構造你獨特的物流戰略。 企業的物流表面上看是貨物的流動，背後是有關客戶需求、服務水平、庫存情況等信息的流動，而根本上也是企業利潤的流動。它可能是你利潤的源泉，也可能會是吞噬企業利潤的無底黑洞。中國的經理人，你在此作何抉擇呢？
7. 有誰知道搜索引擎的資料庫是如何建立的
Google有兩種網路爬蟲，主爬蟲和新爬蟲。主爬蟲主要負責發現新的網頁。一個網頁在新索引建立之後，馬上會被主爬蟲發現。如果一個網頁建立索引需要經過一個月的時間，這個網頁就會失效。
新索引的建立還需要考慮其他非詢問式的決定因素。這些決定因素關系著網頁排名的高低。為了充分利用這些網頁，而不是浪費時間等著下一次索引演算法的更新，Google必須採取一些簡單的措施來猜測排 名，猜測訪客難以利用的新內容是什麼。
盡管Google在作猜測，下列內容都是真實可信的：
1） 幽靈登陸頁上的排名不能等同於索引頁的排名。
2） 在每月新資料庫建立之前，必須將幽靈登陸頁從資料庫中移走。但是，這只是暫時的移走。
如果您的索引中有這樣登陸頁，您的主要目標應該是讓該頁在Google新頁上擁有排名。若您想做到這點，您需要定期、有規律、最好是每天，有一定間隔地更新網站內容。
為什麼您想要在Google的新頁上獲取排名？因為在新頁上有排名的網站更容易被抓取，索引更容易更新。但是在新頁上的排名不是真正的排名，新頁排名有很強的不穩定性。新頁排名轉化為真正排名需要經過一段時間。
案例分析：同樣的遭遇
（1）五天之前，我向互聯網上傳一個新的小網站，這一次我沒有像以往那樣把這個網站與我的其他網站建立鏈接，而是通過添加 l.html將該網址添加到Google中去。我靜靜等待這個網站被發現。三天以 後，用該網站的主要關鍵詞進行搜索，這個網站能排到搜索結果的前十名，並且記錄顯示130個訪問者訪問過該網站。但是，一天之後，這個網站消失了。這一次，他不僅是掉出前十名，而且是掉出整個 Google目錄。網站本身一點問題沒有，沒有作弊，沒有隱藏鏈接，沒有內容復制，沒有關鍵詞堆砌，就這樣默默地網站消失了。
我仔細考慮該網站的欠缺之處，排名消失的原因也許在於這個網站缺少導入鏈接，也許因為這個網站有一個彈出窗口。也許，也許，有無數個也許在等著我。
（2）經常有人向我們咨詢這類問題，為了滿足不同詢問者的需要，我們寫了一篇文章，希望有所幫助。
當 Google搜索蜘蛛抓取一個新網頁後，這個新網頁會有什麼反映？
一個新網頁沒有被Google主目錄收取，直到：
1. 該網頁被Google主目錄搜索蜘蛛抓取。
2. 該網頁在被Google主目錄搜索蜘蛛抓取之後，須經過一段更新時間。
只有以上兩條全都滿足，新網頁被Google主目錄確確實實抓取到，新網頁上的排名才有可能轉化成真正排名 。
Google有兩種抓取形式
1. 主抓取
2. 新抓取
一個新的網頁首先被「新抓取」蜘蛛抓取。但也有特例的時候。在Google月更新剛剛完成那一段時間之後，一個網頁通常被「主抓取」蜘蛛抓取。每月更新一般在每個月的20號到28號之間，能夠持續幾天。
為了區分兩種蜘蛛的差異，我們可以先來看一下一組IP 地址。
1. 「主抓取」蜘蛛= 216.239.46.*
2. 「新抓取」蜘蛛= 64.68.82.*
為了進一步解釋明白新網頁發生的Google幽靈現象，我們假設該網頁首先被「新抓取」蜘蛛抓取。在Google兩個月更新之間，「新抓取」蜘蛛來抓取新網頁。在主抓取期間，通過鏈接新網頁能夠被抓 取。新抓取期間，情況也是一樣。
盡管這個網頁沒有經過此次更新，也沒有收錄在Google主目錄里，但是抓取之後，搜索蜘蛛開始衡量該網頁內容和質量，並把該網頁收錄在搜索結果里。這次衡量是十分不穩定的，易受外界影響，經常發生變化。
當每月定期更新來臨時，這些網頁會產生波動。每月定期更新就是Google波動。但是，您需要記住，「主抓取」蜘蛛沒有閱讀該網頁，所以這個網頁沒有加入主索引中。所以，當每月更新結束後，這個新 網頁仍被看作是新網頁但是不久以後，「主抓取」蜘蛛將會閱讀這個新網頁，在下個月更新之後，該頁面才能被收錄進主索引。這需要經歷一段時間。在此之前，Google不顯示任何導入鏈接，這個網頁的排名也因此多變、不穩定。
讓我們總結一下：
如果一個新網頁首先被一個「新抓取」蜘蛛抓取，然後被「主抓取」蜘蛛抓取，這個網頁需要經過兩次月更新。換句話說，這個新網頁需要經過兩個月才能被主索引收錄，在被主索引收錄之後，才可能獲取穩定的排名。
這期間新網頁可能在Google搜索結果頁中出現，也可能消失，這種不穩定的情況完全是正常的。
還有一種情況。如果一個新網頁首先被「主抓取」蜘蛛抓取（這通常發生在一月的下旬），那麼這個網頁只等一個月的時間就可以進入「主索引」。
網站設計者和擁有者如果不了解Google抓取新網頁的過程，他們的工作將難以開展。網頁排名可能一路飆升，名列前十名，讓人欣喜若狂，也可能陡然狂降，甩出二百名開外，令人垂頭喪氣。抓住 Google抓取新網頁的過程規律，網路英雄們將不再迷茫，有的放矢將不會是單純的夢想。
8. 怎樣建立一個簡單資料庫
具體步驟如下：
1、首先打開我們的access程序，打開方法是單擊開始——所有程序。
9. 我想給一種物品設置一個日期提醒，在資料庫里寫入一個時間，到時間管理員會收到一個提示。
拋磚引玉:
資料庫中寫個存儲過程，找到當天或者一個時間點到期的所有對象，然後在程序裡面定義一個timer,設置間隔時間，然後每次都可以執行下存儲過程，發現有對象，進行提示
10. 簡述一個資料庫應用系統的建立過程
資料庫建立過程包括六個主要步驟：
1．需求分析：了解用戶的數據需求、處理需求、安全和完整性需求。
2．概念設計：通過數據抽象，設計系統的概念模型，一般為e－r模型。
3．邏輯結構設計：設計系統的模式和外部模式，特別是關系模型的基本表和視圖。
4．物理結構設計：設計數據的存儲結構和訪問方法，如索引的設計。
5．系統實現：組織數據存儲，編寫應用程序，試運行。
6．運維：系統投入運行，進行長期維護。
(10)到貨時間資料庫的建立擴展閱讀：
資料庫設計技巧：
1．原始文檔與實體之間的關系
它可以是一對一、一對多、多對多。一般來說，它們是一對一的關系：也就是說，原始文檔只對應於一個實體，而且只對應於一個實體。在特殊情況下，它們可能是一對多或多對一的，其中一個原始文檔對應多個實體，或者多個原始文檔對應一個實體。
這里的實體可以理解為基本表。在明確了這些對應關系之後，這對於輸入介面的設計是非常有益的。
2．主鍵和外鍵
通常，實體不能同時沒有主鍵和外鍵。在e－r關系圖中，葉中的實體可以定義主鍵，也可以不定義主鍵（因為它沒有後代），但是它必須有外鍵（因為它有父鍵）。
主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國的資料庫設計專家說：「鑰匙，鑰匙無處不在，只有鑰匙」，這是他的資料庫設計經驗，也是他高度抽象的信息系統核心思想（數據模型）的體現。
因為：主鍵是實體的高度抽象，主鍵和外鍵對，表示實體之間的連接。
3．基本表的屬性
基表不同於中間表和臨時表，因為它有以下四個特點：
原子性。基表中的欄位沒有分解。
原始性。基表中的記錄是原始數據（底層數據）的記錄。
先驗性。所有輸出數據都可以從基表和代碼表中的數據派生出來。
穩定。表的基本結構比較穩定，表中的記錄保存時間較長。
一旦理解了基本表的性質，就可以在設計資料庫時將它們與中間表和臨時表區分開。