
MySQL Import and Export Application/Functions
- or -
Post a project like this3376
$$$
- Posted:
- Proposals: 5
- Remote
- #938094
- Completed
Description
Experience Level: Expert
General information for the business: We design and manufacture communication products
Kind of development: New program from scratch
Num. of modules: 2
Description of every module: Database Import Module
Database Export Module
Description of requirements/functionality: The application will have two main functions.
1. To Import data from a compound csv text file, into a MySQL database.
2. To export data from the same MySQL database into a compound cvs text file.
The CSV file contains system configuration data which holds data for multiple record types. A sample of the data file is attached to this job description. Along with this is attached a file with the record descriptors of the source data. This sample shows the type of information available to describe the source data.
The data should be imported to databases, tables, fields specified, probably within a config file, but maybe within a database. As yet there is not a defined structure for the import database. The structure can be defined by the developer, and should follow the overall description of the data. References to database table names, field name etc, and references to record names within the import data, and any information specific to data translation or correlation between database ad import file should be coded within a configuration file, not hard coded within the application.
** (additional information) The meaning of the data is not really relevant to the project, it is its structure that is relevant. The data types, array sizes, etc are specified within the descriptor sample I have provided. Although the descriptor document is intentionally incomplete, it describes he type of information available for the data that is to be imported and exported. This information and data samples are probably sufficient to understand the requirements. The field names within the descriptor and sample files are descriptive and should allow records or field collections to be recognisable.
One test of success of the application modules will be the comparison of a file exported from the database, against the same original import file. Therefore retention of the order of records is important as well as the record data itself.
The application will probably be written in Python, but alternatives will be considered depending on the case made. Please be specific about any dependencies of the final application, and the technologies that will be used.
The application(s) will run on a Linux box.
Specific technologies required: MySQL, Linux, Python
OS requirements: Linux
Extra notes: Please identify your experience in the technologies proposed to develop the solution.
**(additional request) If proposing an alternative technology for the development, In a short sentence please state why you would choose this rather than the technologies prescribed.
**(Additional information):
A note about the database usage:
The "primitive" data is imported into a system which "manages" the product from which the data is imported. There is a layer of detail linked with this primitive information which the management system uses, and hence the use of a database to link the higher level information with the primitive data.
It is possible new import/export fields will be introduced over time. It is also possible the array sizes may change.
The import and export process will be infrequent, typically due to configuration changes, but the higher level information is constantly accessible and is used to drive and record data for the overall system.
The imported information will be edited within the database, and new data will be added to it, so it can be subsequently exported from from the database back into the original device.
The descriptor gives a tight data definition, so import conversion into the correct type, and export back out to a text representation should be straightforward, and allows for any data manipulation work required within the database.
For example:
Arrays would be converted into fields within records. Where there are common related fields to form a record, such as the "SUBSCR_SIP_" type, this would result in a SUBSCR_SIP table containing records of the fields:
UA_DATA_CONFIGURED
UA_DATA_SERVER_ID
UA_DATA_SIP_NAME
etc
The table would have a maximum record count of 1000. The idx of each rec reflects where data came from and hence goes back to. The data is then accessible within the database.
For future consideration: One single system may have 1000 records of any one type, but there may end up being a much larger scaled system, responsible for managing many individual systems. This is something that will be developed over time, and will not have a great effect on the initial import/export requirement described in this project, other than perhaps any index sizes selected, which will likely be abstracted in a scaled up project.
Kind of development: New program from scratch
Num. of modules: 2
Description of every module: Database Import Module
Database Export Module
Description of requirements/functionality: The application will have two main functions.
1. To Import data from a compound csv text file, into a MySQL database.
2. To export data from the same MySQL database into a compound cvs text file.
The CSV file contains system configuration data which holds data for multiple record types. A sample of the data file is attached to this job description. Along with this is attached a file with the record descriptors of the source data. This sample shows the type of information available to describe the source data.
The data should be imported to databases, tables, fields specified, probably within a config file, but maybe within a database. As yet there is not a defined structure for the import database. The structure can be defined by the developer, and should follow the overall description of the data. References to database table names, field name etc, and references to record names within the import data, and any information specific to data translation or correlation between database ad import file should be coded within a configuration file, not hard coded within the application.
** (additional information) The meaning of the data is not really relevant to the project, it is its structure that is relevant. The data types, array sizes, etc are specified within the descriptor sample I have provided. Although the descriptor document is intentionally incomplete, it describes he type of information available for the data that is to be imported and exported. This information and data samples are probably sufficient to understand the requirements. The field names within the descriptor and sample files are descriptive and should allow records or field collections to be recognisable.
One test of success of the application modules will be the comparison of a file exported from the database, against the same original import file. Therefore retention of the order of records is important as well as the record data itself.
The application will probably be written in Python, but alternatives will be considered depending on the case made. Please be specific about any dependencies of the final application, and the technologies that will be used.
The application(s) will run on a Linux box.
Specific technologies required: MySQL, Linux, Python
OS requirements: Linux
Extra notes: Please identify your experience in the technologies proposed to develop the solution.
**(additional request) If proposing an alternative technology for the development, In a short sentence please state why you would choose this rather than the technologies prescribed.
**(Additional information):
A note about the database usage:
The "primitive" data is imported into a system which "manages" the product from which the data is imported. There is a layer of detail linked with this primitive information which the management system uses, and hence the use of a database to link the higher level information with the primitive data.
It is possible new import/export fields will be introduced over time. It is also possible the array sizes may change.
The import and export process will be infrequent, typically due to configuration changes, but the higher level information is constantly accessible and is used to drive and record data for the overall system.
The imported information will be edited within the database, and new data will be added to it, so it can be subsequently exported from from the database back into the original device.
The descriptor gives a tight data definition, so import conversion into the correct type, and export back out to a text representation should be straightforward, and allows for any data manipulation work required within the database.
For example:
Arrays would be converted into fields within records. Where there are common related fields to form a record, such as the "SUBSCR_SIP_" type, this would result in a SUBSCR_SIP table containing records of the fields:
UA_DATA_CONFIGURED
UA_DATA_SERVER_ID
UA_DATA_SIP_NAME
etc
The table would have a maximum record count of 1000. The idx of each rec reflects where data came from and hence goes back to. The data is then accessible within the database.
For future consideration: One single system may have 1000 records of any one type, but there may end up being a much larger scaled system, responsible for managing many individual systems. This is something that will be developed over time, and will not have a great effect on the initial import/export requirement described in this project, other than perhaps any index sizes selected, which will likely be abstracted in a scaled up project.

Rob G.
95% (4)Projects Completed
4
Freelancers worked with
4
Projects awarded
50%
Last project
1 Feb 2016
United Kingdom
New Proposal
Login to your account and send a proposal now to get this project.
Log inClarification Board Ask a Question
-
There are no clarification messages.
We collect cookies to enable the proper functioning and security of our website, and to enhance your experience. By clicking on 'Accept All Cookies', you consent to the use of these cookies. You can change your 'Cookies Settings' at any time. For more information, please read ourCookie Policy
Cookie Settings
Accept All Cookies