各位大大~~小人現在正在替人開發一個出單的系統~~~暫時想用access做資料庫~~但不想開放db的source有沒有辦法抽起db的data definition不讓人知道呢?
因為好像pervasive/btrieve 好像可以抽起.ddf~~只開放.dat/.mkd給用戶使用~~可以保護其他人改db內容~~
不知access除了加密外還可以用抽起結構檔來維護嗎?
不好意思呀~~因為初嘗開發~~什麼都不懂~~感謝各位幫忙

有！自訂檔案結構型態！(User defined structure file)，在Delphi就是Record，在C++就是structure。
1.使用自己自行定義的檔案結構好處是結構可以寫在程式裡，當然你要寫在檔案裡面當檔頭也可以（但是要處理的讓別人看不出來），另外就是如果內容也編碼，別人想要看內容或沒有用你自己寫的程式更改是不容易的。
2.相反的也有缺失，就是你必須做好自訂的索引機制，否則以循序(Sequential)的方式來存取搜尋，檔案愈大愈慢～

哦~~原來是這樣~~哪USER DEFINITION FILE要每次訪問都要LOOP嗎?
這幾天在網上看某些文章提及.MDB興.MDE的分別~~自己在家試了~~但打開還是不能察覺到有甚麼分別~~~.MDB與.MDE是不是也有什麼不同的好處呢?
感謝回答

哦~~原來是這樣~~哪USER DEFINITION FILE要每次訪問都要LOOP嗎?
如上所述，你有自訂索引，索引作的好，搜尋演算法寫的完善點（如二分法等，這些都是針對你的索引檔來運作），速度也不會慢到哪裡！因此重點是你如何妥善的處理你的索引檔，怎樣把索引檔作的小些，何時該壓縮小一點，以及怎麼排序，這些OK了，那麼從索引存取主檔就OK。
這幾天在網上看某些文章提及.MDB興.MDE的分別~~自己在家試了~~但打開還是不能察覺到有甚麼分別~~~.MDB與.MDE是不是也有什麼不同的好處呢?
MDE啥我沒見過也沒用過～至於MDB等LOCAL型的資料庫有啥好處，KTOP的一些網友已經有了一些討論，你可以參考看看。
http://delphi.ktop.com.tw/board.php?cid=30&fid=66&tid=89552

有 access 有密碼控制

但是

很容易破

除非你不用資料庫，改用 Stallion 的方式


===================引 用 emilynatiki 文 章===================
各位大大~~小人現在正在替人開發一個出單的系統~~~暫時想用access做資料庫~~但不想開放db的source有沒有辦法抽起db的data definition不讓人知道呢?
因為好像pervasive/btrieve 好像可以抽起.ddf~~只開放.dat/.mkd給用戶使用~~可以保護其他人改db內容~~
不知access除了加密外還可以用抽起結構檔來維護嗎?
不好意思呀~~因為初嘗開發~~什麼都不懂~~感謝各位幫忙

就資料庫架構不想讓其他廠商 或潛在進入者,輕鬆整個模仿學走,

聽過,有廠商的作法就是把表格 Id, 欄位ID,..等 取無意義的ID.


增加 模仿者所需的時間 跟難度,.


主 要是要是能 延後模仿者幾個月,或一兩年,拉高對手成本,
不然經過長時間開發,
才上市佔有率還沒拉高,
就有一堆相關產品低價搶單,恐怕會入不敷出..



因為自己人有文件,或有註解可看,原開發人員經驗豐富,或主架構已經穩定很少需要大修改等,

反正自己人看的懂,就算維護上是有多一點不便,

但整體而言 ,應該就是 利大於弊 才會這樣作.



自己衡量情況.





===================引 用 emilynatiki 文 章===================
各位大大~~小人現在正在替人開發一個出單的系統~~~暫時想用access做資料庫~~但不想開放db的source有沒有辦法抽起db的data definition不讓人知道呢?
因為好像pervasive/btrieve 好像可以抽起.ddf~~只開放.dat/.mkd給用戶使用~~可以保護其他人改db內容~~
不知access除了加密外還可以用抽起結構檔來維護嗎?
不好意思呀~~因為初嘗開發~~什麼都不懂~~感謝各位幫忙

小弟要先向Stallion版大說聲抱歉。
小弟不是要挑戰版大，不過，論壇就是大家討論，百無禁忌啦。

版大講的，一定是開玩笑。除非是很小很小，或很特殊的應用，及很暫時性的須求，才可能會用版大講的這種結構，才對。
而且也必定是沒有升級或移殖的問題，才可能不用資料庫。
現在沒用SQL，要自己來，很麻煩吧。

Access的保安措施就像鎖或鐵窗一般，是要鎖自己的。只能防君子，不能妨小人的。
唯一的路就是像System72兄講的，從表格與欄位命名來處理了。不過，如果結構簡單，擋不住人。結構複雜，那有只是多攔別人一些時間，及給自己多很多麻煩與增加自己維護的成本罷了。

唯一的路就是像System72兄講的，從表格與欄位命名來處理了。

------
Kevin

編輯記錄

Kevin兄多慮了～論壇本就是觀念作法討論，何來抱歉！不過我所說的是本身實務！
有現成的資料庫或資料庫伺服器不用？！我同意你，那個人不是天才，就是傻子，不然就是有難言之隱。對一般人而言，要寫出一個比MSSQL或者是其他大牌子資料庫伺服器好的資料庫引擎，就像是「湯姆克魯斯」演的電影名稱一樣 Mission impossible ！
但是上述我的論點（其實也是我自己實務經驗）是針對本篇提出的問題來討論的，為何我如此說呢？最主要的問題在於引用現行市場上的資料庫，又不想其他人對你的資料表中的資料亂動手腳真的很難，最多誠如以上各位所述，加上一些技巧增加別人想要偷雞時，必須要花很大的心思與成本來增加困難度，但請不要忘記那些資料庫表格資訊終究是公開的，甚或還有第三方發展提供一些處理的工具，因此別人偷雞成功的功算相對很大！
自訂格式的好處是格式是私密的，再加上資料編碼，如果你的公司單位沒有內賊將資訊洩漏，別人惡搞偷雞成功的機率幾乎是零！但同時我也同意，為了維護這種格式，自己製作索引與何時該壓縮與資料匯出入的工程，只有兩個字「辛苦」！而且效能絕對沒有辦法與M＄牌子相比擬，我的經驗是（有點久遠了，數據不敢說很精準）每筆Record在幾K約一萬筆時，處理資料速度還差強人意。我不知道出單系統資料每筆有多大？就算是大牌子的資料庫總是也要索引、壓縮維護或者匯出保存的，這些工作設計的好，自訂資料格式檔案的效能總會有一定的水準。
最後我的想法是，當你的商品必須快速搶佔先機又沒有資料格式內容外洩的問題，那麼我的說法不足取。但當你的商品資訊技術機密非常不想讓外人知道，可以考慮我的作法，如此你的商品安全強度才夠，當錢賺夠了回過頭來想想怎麼強化與加速自訂的資料存取機制，才能擁有長遠的優勢。
===================引 用 kevin2004 文 章===================
小弟要先向Stallion版大說聲抱歉。
小弟不是要挑戰版大，不過，論壇就是大家討論，百無禁忌啦。

版大講的，一定是開玩笑。除非是很小很小，或很特殊的應用，及很暫時性的須求，才可能會用版大講的這種結構，才對。
而且也必定是沒有升級或移殖的問題，才可能不用資料庫。
現在沒用SQL，要自己來，很麻煩吧。

Access的保安措施就像鎖或鐵窗一般，是要鎖自己的。只能防君子，不能妨小人的。
唯一的路就是像System72兄講的，從表格與欄位命名來處理了。不過，如果結構簡單，擋不住人。結構複雜，那有只是多攔別人一些時間，及給自己多很多麻煩與增加自己維護的成本罷了。

唯一的路就是像System72兄講的，從表格與欄位命名來處理了。

自行處理剛開始會有較多基本功要處理.

比較適合程式基礎較深厚,
或較有時間的,
或者已經有類別庫/程式庫,或有人教,

自己開發相關程式庫,類別庫測到穩定,除錯,
這需要一段時間,說 辛苦 也滿貼切.



不過,速度,或整體考量這個就很難說了,

像BBS 架在在一台PC上,512MB Ram,
就可以給數百人上線.
如果在一台同樣的硬體規格的PC, 裝 DB ,那恐怕不到50個人同時上線後,就開始慢起來的.



適不適合,需不需要,還真的要看問題的應用,才比較好決定.


另外,值不值得去最佳化是一個問題,

可以針對 1萬筆,或10萬筆,或100萬筆來規劃,做最佳化,
根據資料特性,使用不同的快取索引等,效率也可以很高.



如果你程式需要很快的 Data IO,
做資料的即時處理,
有時候就是要自行處理才會真的快,
最後歸檔或備份時在寫回資料庫



===================引 用 Stallion 文 章===================
Kevin兄多慮了～論壇本就是觀念作法討論，何來抱歉！不過我所說的是本身實務！
有現成的資料庫或資料庫伺服器不用？！我同意你，那個人不是天才，就是傻子，不然就是有難言之隱。對一般人而言，要寫出一個比MSSQL或者是其他大牌子資料庫伺服器好的資料庫引擎，就像是「湯姆克魯斯」演的電影名稱一樣 Mission impossible ！
但是上述我的論點（其實也是我自己實務經驗）是針對本篇提出的問題來討論的，為何我如此說呢？最主要的問題在於引用現行市場上的資料庫，又不想其他人對你的資料表中的資料亂動手腳真的很難，最多誠如以上各位所述，加上一些技巧增加別人想要偷雞時，必須要花很大的心思與成本來增加困難度，但請不要忘記那些資料庫表格資訊終究是公開的，甚或還有第三方發展提供一些處理的工具，因此別人偷雞成功的功算相對很大！
自訂格式的好處是格式是私密的，再加上資料編碼，如果你的公司單位沒有內賊將資訊洩漏，別人惡搞偷雞成功的機率幾乎是零！但同時我也同意，為了維護這種格式，自己製作索引與何時該壓縮與資料匯出入的工程，只有兩個字「辛苦」！而且效能絕對沒有辦法與M＄牌子相比擬，我的經驗是（有點久遠了，數據不敢說很精準）每筆Record在幾K約一萬筆時，處理資料速度還差強人意。我不知道出單系統資料每筆有多大？就算是大牌子的資料庫總是也要索引、壓縮維護或者匯出保存的，這些工作設計的好，自訂資料格式檔案的效能總會有一定的水準。
最後我的想法是，當你的商品必須快速搶佔先機又沒有資料格式內容外洩的問題，那麼我的說法不足取。但當你的商品資訊技術機密非常不想讓外人知道，可以考慮我的作法，如此你的商品安全強度才夠，當錢賺夠了回過頭來想想怎麼強化與加速自訂的資料存取機制，才能擁有長遠的優勢。
===================引 用 kevin2004 文 章===================
小弟要先向Stallion版大說聲抱歉。
小弟不是要挑戰版大，不過，論壇就是大家討論，百無禁忌啦。

版大講的，一定是開玩笑。除非是很小很小，或很特殊的應用，及很暫時性的須求，才可能會用版大講的這種結構，才對。
而且也必定是沒有升級或移殖的問題，才可能不用資料庫。
現在沒用SQL，要自己來，很麻煩吧。

是針對本篇提出的問題來討論的

呵、呵，版大講的有理。

------
Kevin

給你幾點建議：

1. 自己寫資料庫結構。我以前在DOS下用Basic 做過，十分辛苦。
若要提高讀寫效率，採用二元樹 Double Link List 。
太累了。目前是21世紀不建議如此。

2. 使用MDE 。可撰寫VBA程式 在MDB 裡，禁止ACCESS開啟。
編譯為 MDE 就無法看到或編輯程式。

參考

講點個人感受。
其實，破解資料結構其實不難，甚至根本不用打開他的資料庫，只要看看系統流程及報表等等，大家應該就可以也設計出來八九不離十地的結構來。甚至比他原先的更好。
輪子不是一直被重覆地被發明出來的嗎。
重點是你的程式碼。其實程式碼也沒啥難，誰都寫地出來。就看你的經驗與肯花多少工了。
差的系統寫一千行，好的系統可能要八千或兩萬行，純是工與經驗了。

不要太執著你原先的考量。

------
Kevin

編輯記錄