食谱搜寻系统未来展望

小白食谱搜寻系统缺点
(要说缺点真的是一大堆)/images/emoticon/emoticon02.gif

  1. 属性不足 : 最大的缺点就是在食材、调味料和做法的栏位没有设置足够的属性,导致有些制作过程较麻烦和需要准备较多食材的料理就无法加入资料库,因此降低资料库的丰富度。
  2. 实用性低 : 由於系统的制作是Icebear用来展示MySQL 和node.js的学习结果,只能在Notepad++ 或Vscode等编译器利用程序码下指令,并且在cmd或虚拟终端机执行程序,所以完全没有实用性。
  3. 资料库资料杂乱 :由於这次Icebear存入资料库的料理数量不是很多,所以就没有在意整齐性的问题,导致之後资料量变多时,所有料理都存在一个资料表。
  4. Demo问题 :只有呈现料理简介及食材准备,没有呈现制作方法和调味料准备的内容
  5. 程序执行结果问题 :由於有些料理的制作步骤可能必较简单,所以可能不会用到全部的属性栏位,但在结果呈现时还是会把空的属性呈现出来,造成呈现结果凌乱

小白食谱搜寻系统未来展望/images/emoticon/emoticon08.gif

  1. 启用共用制度 : 好朋友间可以利用共用的方式,可以将新的料理加入系统,增加系统的更新能力。
  2. 整理资料表 : 如上Icebear所提到的,可能可以将归类为主菜的料理存放在同一个资料表,并且与其他种类的料理区分,以免日後资料存放过多。
  3. 制作成网站 :将系统制作成网站增加实用性,增加一些排版设计,在视觉上会大大提升舒适度。
  4. 加入图片 : 制作网站後可以加入图片,在制作步骤上和成品可以有示意图,而非只有文字叙述,可以增加制作成功率。
  5. 由於系统对於资料库的搜寻指令比较单一,因此呈现的料理资料非常有限,日後Icebear会更新搜寻内容,让料理简介的结果更加完整。
  6. Icebear之後会研究看看是否能在搜寻结果呈现时,不呈现属性为空值的栏位,让结果呈现比较整齐一点

<<:  [D23] 物件侦测(4)

>>:  后续说明

【Day12】漏洞分析Vulnerability Analysis(一)

哈罗~ 前面几天我们介绍了线上情蒐工具、网路扫描与列举技术, 而攻击者会利用软件或硬体的不完善来对组...

Day17 - 物理模拟篇 - 弹力、引力与磁力II - 成为Canvas Ninja ~ 理解2D渲染的精髓

在上一篇文中我们提到了一维弹力模拟的案例 这次我们则是要实作二维弹力模拟~并且是存在重力场的状态! ...

Day6 PHP变量

变量或称变数,是是用於存储信息的容器。 x='winnie'; y=5; 在数学代数中,使用字母(如...

【Day26】:从struct进化成class的物件导向技巧(下)

建构子 建构子(constructor)是一种初始化类别物件的成员函式,每一种类别都有一个建构子,当...

Day 27 建立 Switch

实作 import React, { useState } from 'react'; import...