title: Permanent vs temporary table for directory import
body: <p>Question: Is there any thing bad about constantly droping a table and recreating it as needed for importing file structure in to a database.  each user would get their own table if the table exists recovery from last import starts?  below are the details.  </p>
  
  <p>I am working on a file import project and am planning to do a dynamic or temporary table to read the contents of the users folder and then import in to the database. there are known data inconsistancy's like !#% in the file/folder path. part of the import is to try and find neumeric data at the end of the file/folder path "ron &amp; jared's visit # 3" would be an example i am using php 5.6 and mariadb 5.5.  since the folder information is so messed up and users are not likely to always remember, I need to know if using a table and trashing it after import is complete would have any negitive side affects.</p>
  
  <p>I am tempted to make a real table  import_userID for each import and if their import session fails for any reason from power outage to a bug I didn't catch in the handling of bad char's in a folder it can be resumed next time the user attempts to import. going to the import files page would do a check for table import_userID if exists read last line and spit out  import failed after  "....." it would then try to reread the directory and print out a directory tree.  I am attempting to normalize things to  import folder/incident001/visit001/file001.... </p>
  
  <p>once the file structure is read in to the table the php script will then attempt to normalize for the user and display warnings on any folders that didnt normalize well. the user will be then prompted to fix the directory/file structure according to a template given with dropdowns of either missing or next visit #  visit002 visit007 visit025 etc so that the user is forced to correct things in to the normalized folder/file structure. the files/folders are then renamed and put in to a zip file which on submit will copy the new normalized file path's and zip file destination to the database and move the zip on to the web servers file system in the right location.  </p>
  
  <p>id/original file location/normalized file location  would be the extent of the columns in the table. the directory read would fill in the original and after the user sorts out normalization it would then fill in normalized column. run a rename from files/visits/incidents in that order then use it to zip the incident folders in to seperate zip files and store them away. once complete it would finally drop import_userID.</p>
  
  <p>the largest I know of is about 1000 visit folders with a couple hundred incident folders. average is a couple incident and 30 or so visit folders.   </p>