关于data entry validation

hk

发现某些程式员在写data entry validation时，会用DDL去取database table structure的资料来做参考，譬如query field size来set textbox的maxlength等等。。
没错，这看起来非常专业，不过，从另一个角度来看，
每次load form时，都要去query 那个field size，这样做不是影响到了整个程式的运行速度吗？
况且写完程式后，我们会有多少机会去改那个field size呢？

yan13

個人猜測,可能不是為了pro,只是為了方便和避免人工設定的失誤.
就是說你只要copy and paste,改一小段就完全可以不用去查看database structure.

hk

yan13 发表于 25-12-2018 09:20 PM
個人猜測,可能不是為了pro,只是為了方便和避免人工設定的失誤.
就是說你只要copy and paste,改一小段就完全可以不用去查看database structure.

嗯，同意这也是其中一个原因，不过我觉得编程最重要的还是运行速度，或许编程过程是方便了，但是想想一个程式可能会用上10年20年，一天可能会执行几十到几百次，
每次开form都要先query， loop table拿field type, data size等等这些无谓的过程，耗费用户电脑资源和时间。

觉得人工失誤问题应该从testing那边着手，一劳永逸，不是么？

yan13

hk 发表于 25-12-2018 11:52 PM
嗯，同意这也是其中一个原因，不过我觉得编程最重要的还是运行速度，或许编程过程是方便了，但是想想一个程式可能会用上10年20年，一天可能会执行几十到几百次，
每次开form都要先query， loop table拿field type ...

以目前來說,我個人還是傾向在程系上做設定,除非database admin不是我.

hk

yan13 发表于 26-12-2018 04:15 PM
以目前來說,我個人還是傾向在程系上做設定,除非database admin不是我.

还有一种情况就是做add， edit data时，用loop form control的方式来做update，fieldname放在tag那边，这个我就没有异议。

musicalangel

我比較偏向 PHP 那方面的.
最近的趨勢都是根據Framework 的寫法, 寫死寫成一個function/method/class

跨Project的時候, 就把舊有的 class 一起帶過去.
很少有像樓主說的那樣, 在DLL裡面去refer DB Field 的屬性.

hk

musicalangel 发表于 13-1-2019 01:22 PM
我比較偏向 PHP 那方面的.
最近的趨勢都是根據Framework 的寫法, 寫死寫成一個function/method/class

跨Project的時候, 就把舊有的 class 一起帶過去.
很少有像樓主說的那樣, 在DLL裡面去refer DB Field 的屬性 ...

是的，是一个vb6的旧系统来的，用户有source code要求做database covertion，
研究了系统，发现系统每次load form时会loop整个table structure和field 的屬性，
然后做相关的处理，field size来set textbox的maxlength是其中一个例子。
而且form，control size，position等等都是系统计算出来的。
每个table都有一个class来处理。
系统还同时可以support MS Access和MS Sql Server（在startup那边check）。

这个系统看起来非常pro，不过就是觉得有点慢，那些东西拿掉的话，就快很多了。
我是觉得系统快才是王道。

musicalangel

你讓我想到, 以前我也是很猶豫關於ORM這類型的東西, 很多人說他很慢, 累贅, 所以我剛開始學Framework的時候還是很堅持用Query builder 或者輸入原始的SQL.

可能是年紀變大, 性情變懶惰了.
也有可能是因為 PHP 跨入 7 的時候, 執行速度的進步.

後續我在學另外一套 Framework (Laravel) 的時候, 對 ORM 可是愛不釋手, 基本上可以用 ORM 解決的問題, 我開始不去考慮使用SQL.

最後漸漸改觀成, 茶或咖啡各有所好. 如果跟同行在一起開發程式的時候, 大家都會達成一個共識, 就是你用你的model, 我用我的, 在系統內不相衝就好.

給你參考參考.

Booking707

有没有人会写Data Entry Program 和 Data Entry App 给公司记录订单和Print报告
请私聊PM。

flashang

随便说说一个代替方案。

可以做一个独立的 “check db” 把资料储存在一个额外的 file，有更改 db structure 的时候使用，也可以在程式开始的时候更新。
主程式一开始就读这个 file，并且保留资料在 ram 直到程式结束。
check data type / size 改成在 ram 里面查。
这样做可以减少重复的读取，提高效率，也不必大改。

hk

flashang 发表于 8-6-2019 12:59 AM
随便说说一个代替方案。

可以做一个独立的 “check db” 把资料储存在一个额外的 file，有更改 db structure 的时候使用，也可以在程式开始的时候更新。
主程式一开始就读这个 file，并且保留资料在 ram 直到程 ...

这个方法可真没想过。。

你的意思是譬如Employee Table, 我们把他的属性EmpCode varchar(10), EmpName varchar(50)，BasicSalary decimal (15,2) 等等写在一个file，然后load form时读那个file取field type，size来set textbox maxlength和做validation等？
不过如果我们以后决定把EmpName varchar(50)改去EmpName varchar(100)后，我们除了要改DB，也要去改那个file，也是2个动作，而且一开始跑程序时还要特意去读取那个file ?

hk

musicalangel 发表于 14-1-2019 09:17 PM
你讓我想到, 以前我也是很猶豫關於ORM這類型的東西, 很多人說他很慢, 累贅, 所以我剛開始學Framework的時候還是很堅持用Query builder 或者輸入原始的SQL.

可能是年紀變大, 性情變懶惰了.
也有可能是因為 PHP 跨 ...

一路来写惯了sql，总是觉得他是比较native的，那些sql builder从来没用过。
好奇Laravel ORM可以应付那些complex的query吗？譬如需要到很多的subquery，temporary table这些？

flashang

hk 发表于 8-6-2019 09:08 AM
这个方法可真没想过。。

你的意思是譬如Employee Table, 我们把他的属性EmpCode varchar(10), EmpName varchar(50)，BasicSalary decimal (15,2) 等等写在一个file，然后load form时读那个file取field type，si ...

差不多是这个意思，当然可以做得更方便。


一般上 database structure 不常修改。
可以把 update database 分开做成另外一个 exe 或者另外一个 button / form。
执行 update database 的时候，应该自动更新那个 file。


当你有不同的电脑都有这个软件，更新就比较少问题。


主程式一开始读取那个 file 是为了减少之后的每一个 form 都需要去检查 database structure。

hk

flashang 发表于 8-6-2019 10:01 AM
差不多是这个意思，当然可以做得更方便。


一般上 database structure 不常修改。
可以把 update database 分开做成另外一个 exe 或者另外一个 button / form。[/backco ...

我目前也是做一个exe来update db structure，连同一个新program的exe（改validation/input property），validation就在db的class做。

flashang

hk 发表于 8-6-2019 11:39 AM
我目前也是做一个exe来update db structure，连同一个新program的exe（改validation/input property），validation就在db的class做。

validation 在 user input mask 或者 before insert / update, 都可以。
减少重复读取 db structure,
而且每一次都是一样的没必要。
开始的时候做一次就好了。

hk

flashang 发表于 8-6-2019 12:33 PM
validation 在 user input mask 或者 before insert / update, 都可以。
减少重复读取 db structure,
而且每一次都是一样的没必要。
开始的时候做一次就好了。

是的，我也是这样认为的。

不过再回想这样子的设计，是不是有更深一层的考量？ 况且硬件的速度一直在提升（processor，ram，ssd越来越快和便宜），会不会多虑了？
甚至，form里面control的aligment也是auto计算出来的（based on screen resolution），save/edit record也是automate的，fieldname放在tag，
只要invoke一个common function就可以完成save/edit了（loop form control）。程式员只注重business logic就可以了。

想想这种全部automate的方式，会减轻很多软件开发的成本，尤其是大系统。

flashang

hk 发表于 9-6-2019 11:03 AM
是的，我也是这样认为的。

不过再回想这样子的设计，是不是有更深一层的考量？ 况且硬件的速度一直在提升（processor，ram，ssd越来越快和便宜），会不会多虑了？
甚至，form里面control的aligment也是auto计 ...

不同的时候，不同的工作环境，工具，会有更适合的方法。

这个 vb6 的程式可能会遇到一些问题 :
vb6 已经没有更新，漏洞/缺失的功能可能需要花很大的力气处理。
要找新人接手需要花时间训练 vb6 的工作方式。
目前的系统是可以执行，以后就不一定，或许需要使用 emulator.

如果找到设计的人，或许可以知道这样做的原因。
但是，很可能会需要用新的工具重做。

yan13

hk 发表于 9-6-2019 11:03 AM
是的，我也是这样认为的。

不过再回想这样子的设计，是不是有更深一层的考量？ 况且硬件的速度一直在提升（processor，ram，ssd越来越快和便宜），会不会多虑了？
甚至，form里面control的aligment也是auto计 ...

選擇吧?要容易開發而少問題還是要執行速度快?聽說本地在dos時代就已經有database driven的軟件了.
硬件的快速發展也讓公司能夠考慮一些執行速度比較慢,但相對來說開發成本比較低的方案

hk

flashang 发表于 9-6-2019 12:44 PM
不同的时候，不同的工作环境，工具，会有更适合的方法。

这个 vb6 的程式可能会遇到一些问题 :
vb6 已经没有更新，漏洞/缺失的功能可能需要花很大的力气处理。
要找新人接手需要花时间训练 vb6 的工作方式 ...

是一家本地蛮大的软件公司，软件还销售到中国，东南亚一些国家，听用户说公司转型去开发其他系统了，所以这些erp系统只能用到不能用为止才会叫人重新写过。

hk

yan13 发表于 9-6-2019 01:15 PM
選擇吧?要容易開發而少問題還是要執行速度快?聽說本地在dos時代就已經有database driven的軟件了.
硬件的快速發展也讓公司能夠考慮一些執行速度比較慢,但相對來說開發成本比較低的方案

觉得现在很多系统执行速度上比以前的系统慢很多，尤其web-based的，用了很多3rd party的component（例如devexpress等等），用户体验是提升了，不过速度是一根刺啊
不过站在商业的角度，界面和用户体验，始终是王道。

其实我本身现在还有客户在用着DOS系统，clipper+dbase database，配合dox matrix printer，从1991用到现在，算算28年了。。一些硬件坏了，我帮他们install DosBox继续在win7跑。