access 保密問題 |
缺席
|
emilynatiki
一般會員 發表:5 回覆:8 積分:2 註冊:2007-02-10 發送簡訊給我 |
|
Stallion
版主 發表:52 回覆:1600 積分:1995 註冊:2004-09-15 發送簡訊給我 |
|
emilynatiki
一般會員 發表:5 回覆:8 積分:2 註冊:2007-02-10 發送簡訊給我 |
|
Stallion
版主 發表:52 回覆:1600 積分:1995 註冊:2004-09-15 發送簡訊給我 |
哦~~原來是這樣~~哪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 |
syntax
尊榮會員 發表:26 回覆:1139 積分:1258 註冊:2002-04-23 發送簡訊給我 |
有 access 有密碼控制
但是 很容易破 除非你不用資料庫,改用 Stallion 的方式 ===================引 用 emilynatiki 文 章=================== 各位大大~~小人現在正在替人開發一個出單的系統~~~暫時想用access做資料庫~~但不想開放db的source有沒有辦法抽起db的data definition不讓人知道呢? 因為好像pervasive/btrieve 好像可以抽起.ddf~~只開放.dat/.mkd給用戶使用~~可以保護其他人改db內容~~ 不知access除了加密外還可以用抽起結構檔來維護嗎? 不好意思呀~~因為初嘗開發~~什麼都不懂~~感謝各位幫忙 |
system72
中階會員 發表:15 回覆:114 積分:55 註冊:2005-08-17 發送簡訊給我 |
就資料庫架構不想讓其他廠商 或潛在進入者,輕鬆整個模仿學走,
聽過,有廠商的作法就是把表格 Id, 欄位ID,..等 取無意義的ID. 增加 模仿者所需的時間 跟難度,. 主 要是要是能 延後模仿者幾個月,或一兩年,拉高對手成本, 不然經過長時間開發, 才上市佔有率還沒拉高, 就有一堆相關產品低價搶單,恐怕會入不敷出.. 因為自己人有文件,或有註解可看,原開發人員經驗豐富,或主架構已經穩定很少需要大修改等, 反正自己人看的懂,就算維護上是有多一點不便, 但整體而言 ,應該就是 利大於弊 才會這樣作. 自己衡量情況. ===================引 用 emilynatiki 文 章=================== 各位大大~~小人現在正在替人開發一個出單的系統~~~暫時想用access做資料庫~~但不想開放db的source有沒有辦法抽起db的data definition不讓人知道呢? 因為好像pervasive/btrieve 好像可以抽起.ddf~~只開放.dat/.mkd給用戶使用~~可以保護其他人改db內容~~ 不知access除了加密外還可以用抽起結構檔來維護嗎? 不好意思呀~~因為初嘗開發~~什麼都不懂~~感謝各位幫忙 |
kevin2004
資深會員 發表:18 回覆:463 積分:416 註冊:2005-05-29 發送簡訊給我 |
小弟要先向Stallion版大說聲抱歉。
小弟不是要挑戰版大,不過,論壇就是大家討論,百無禁忌啦。 版大講的,一定是開玩笑。除非是很小很小,或很特殊的應用,及很暫時性的須求,才可能會用版大講的這種結構,才對。 而且也必定是沒有升級或移殖的問題,才可能不用資料庫。 現在沒用SQL,要自己來,很麻煩吧。 Access的保安措施就像鎖或鐵窗一般,是要鎖自己的。只能防君子,不能妨小人的。 唯一的路就是像System72兄講的,從表格與欄位命名來處理了。不過,如果結構簡單,擋不住人。結構複雜,那有只是多攔別人一些時間,及給自己多很多麻煩與增加自己維護的成本罷了。 唯一的路就是像System72兄講的,從表格與欄位命名來處理了。
------
Kevin
編輯記錄
kevin2004 重新編輯於 2007-08-05 20:34:16, 註解 無‧
|
Stallion
版主 發表:52 回覆:1600 積分:1995 註冊:2004-09-15 發送簡訊給我 |
Kevin兄多慮了~論壇本就是觀念作法討論,何來抱歉!不過我所說的是本身實務!
有現成的資料庫或資料庫伺服器不用?!我同意你,那個人不是天才,就是傻子,不然就是有難言之隱。對一般人而言,要寫出一個比MSSQL或者是其他大牌子資料庫伺服器好的資料庫引擎,就像是「湯姆克魯斯」演的電影名稱一樣 Mission impossible ! 但是上述我的論點(其實也是我自己實務經驗)是針對本篇提出的問題來討論的,為何我如此說呢?最主要的問題在於引用現行市場上的資料庫,又不想其他人對你的資料表中的資料亂動手腳真的很難,最多誠如以上各位所述,加上一些技巧增加別人想要偷雞時,必須要花很大的心思與成本來增加困難度,但請不要忘記那些資料庫表格資訊終究是公開的,甚或還有第三方發展提供一些處理的工具,因此別人偷雞成功的功算相對很大! 自訂格式的好處是格式是私密的,再加上資料編碼,如果你的公司單位沒有內賊將資訊洩漏,別人惡搞偷雞成功的機率幾乎是零!但同時我也同意,為了維護這種格式,自己製作索引與何時該壓縮與資料匯出入的工程,只有兩個字「辛苦」!而且效能絕對沒有辦法與M$牌子相比擬,我的經驗是(有點久遠了,數據不敢說很精準)每筆Record在幾K約一萬筆時,處理資料速度還差強人意。我不知道出單系統資料每筆有多大?就算是大牌子的資料庫總是也要索引、壓縮維護或者匯出保存的,這些工作設計的好,自訂資料格式檔案的效能總會有一定的水準。 最後我的想法是,當你的商品必須快速搶佔先機又沒有資料格式內容外洩的問題,那麼我的說法不足取。但當你的商品資訊技術機密非常不想讓外人知道,可以考慮我的作法,如此你的商品安全強度才夠,當錢賺夠了回過頭來想想怎麼強化與加速自訂的資料存取機制,才能擁有長遠的優勢。 ===================引 用 kevin2004 文 章=================== 小弟要先向Stallion版大說聲抱歉。 小弟不是要挑戰版大,不過,論壇就是大家討論,百無禁忌啦。 版大講的,一定是開玩笑。除非是很小很小,或很特殊的應用,及很暫時性的須求,才可能會用版大講的這種結構,才對。 而且也必定是沒有升級或移殖的問題,才可能不用資料庫。 現在沒用SQL,要自己來,很麻煩吧。 Access的保安措施就像鎖或鐵窗一般,是要鎖自己的。只能防君子,不能妨小人的。 唯一的路就是像System72兄講的,從表格與欄位命名來處理了。不過,如果結構簡單,擋不住人。結構複雜,那有只是多攔別人一些時間,及給自己多很多麻煩與增加自己維護的成本罷了。 唯一的路就是像System72兄講的,從表格與欄位命名來處理了。 |
system72
中階會員 發表:15 回覆:114 積分:55 註冊:2005-08-17 發送簡訊給我 |
自行處理剛開始會有較多基本功要處理. 比較適合程式基礎較深厚, 或較有時間的, 或者已經有類別庫/程式庫,或有人教, 自己開發相關程式庫,類別庫測到穩定,除錯, 這需要一段時間,說 辛苦 也滿貼切. 不過,速度,或整體考量這個就很難說了, 像BBS 架在在一台PC上,512MB Ram, 就可以給數百人上線. 如果在一台同樣的硬體規格的PC, 裝 DB ,那恐怕不到50個人同時上線後,就開始慢起來的. 適不適合,需不需要,還真的要看問題的應用,才比較好決定. 另外,值不值得去最佳化是一個問題, 可以針對 1萬筆,或10萬筆,或100萬筆來規劃,做最佳化, 根據資料特性,使用不同的快取索引等,效率也可以很高. 如果你程式需要很快的 Data IO, 做資料的即時處理, 有時候就是要自行處理才會真的快, 最後歸檔或備份時在寫回資料庫 ===================引 用 Stallion 文 章=================== Kevin兄多慮了~論壇本就是觀念作法討論,何來抱歉!不過我所說的是本身實務! 有現成的資料庫或資料庫伺服器不用?!我同意你,那個人不是天才,就是傻子,不然就是有難言之隱。對一般人而言,要寫出一個比MSSQL或者是其他大牌子資料庫伺服器好的資料庫引擎,就像是「湯姆克魯斯」演的電影名稱一樣 Mission impossible ! 但是上述我的論點(其實也是我自己實務經驗)是針對本篇提出的問題來討論的,為何我如此說呢?最主要的問題在於引用現行市場上的資料庫,又不想其他人對你的資料表中的資料亂動手腳真的很難,最多誠如以上各位所述,加上一些技巧增加別人想要偷雞時,必須要花很大的心思與成本來增加困難度,但請不要忘記那些資料庫表格資訊終究是公開的,甚或還有第三方發展提供一些處理的工具,因此別人偷雞成功的功算相對很大! 自訂格式的好處是格式是私密的,再加上資料編碼,如果你的公司單位沒有內賊將資訊洩漏,別人惡搞偷雞成功的機率幾乎是零!但同時我也同意,為了維護這種格式,自己製作索引與何時該壓縮與資料匯出入的工程,只有兩個字「辛苦」!而且效能絕對沒有辦法與M$牌子相比擬,我的經驗是(有點久遠了,數據不敢說很精準)每筆Record在幾K約一萬筆時,處理資料速度還差強人意。我不知道出單系統資料每筆有多大?就算是大牌子的資料庫總是也要索引、壓縮維護或者匯出保存的,這些工作設計的好,自訂資料格式檔案的效能總會有一定的水準。 最後我的想法是,當你的商品必須快速搶佔先機又沒有資料格式內容外洩的問題,那麼我的說法不足取。但當你的商品資訊技術機密非常不想讓外人知道,可以考慮我的作法,如此你的商品安全強度才夠,當錢賺夠了回過頭來想想怎麼強化與加速自訂的資料存取機制,才能擁有長遠的優勢。 ===================引 用 kevin2004 文 章=================== 小弟要先向Stallion版大說聲抱歉。 小弟不是要挑戰版大,不過,論壇就是大家討論,百無禁忌啦。 版大講的,一定是開玩笑。除非是很小很小,或很特殊的應用,及很暫時性的須求,才可能會用版大講的這種結構,才對。 而且也必定是沒有升級或移殖的問題,才可能不用資料庫。 現在沒用SQL,要自己來,很麻煩吧。 |
kevin2004
資深會員 發表:18 回覆:463 積分:416 註冊:2005-05-29 發送簡訊給我 |
|
wameng
版主 發表:31 回覆:1336 積分:1188 註冊:2004-09-16 發送簡訊給我 |
|
kevin2004
資深會員 發表:18 回覆:463 積分:416 註冊:2005-05-29 發送簡訊給我 |
講點個人感受。
其實,破解資料結構其實不難,甚至根本不用打開他的資料庫,只要看看系統流程及報表等等,大家應該就可以也設計出來八九不離十地的結構來。甚至比他原先的更好。 輪子不是一直被重覆地被發明出來的嗎。 重點是你的程式碼。其實程式碼也沒啥難,誰都寫地出來。就看你的經驗與肯花多少工了。 差的系統寫一千行,好的系統可能要八千或兩萬行,純是工與經驗了。 不要太執著你原先的考量。
------
Kevin
編輯記錄
kevin2004 重新編輯於 2007-08-07 13:31:07, 註解 無‧
|
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |