I have a large database of client details, and I need to generate a totally new field of data based on a single other field. It would be a simple IF..THEN deal.
Example:
The source field has data that looks like this "BAR DIN" (Barrie Dinners) and I need to fill a new field with "Dinners".
From what I understand, Data Macros are the right way to do this, but I'd prefer not to buy Access 2010. There should be a way to do this with normal macros. This update only needs to be done once a year and can be done manually. I mostly looking for a way to avoid having to enter all that data manually for each customer.
Create a separate table to translate between the two:
source_field new_field
BAR DIN Barrie Dinners
FOO BROS Foo Brothers
Anytime you need to see the "new_field" values, JOIN that translation table to your original table (JOIN on source_field) to look them up. This approach is one of the fundamental reasons relational databases were created in the first place. This way your database will always be "up to date" without the need for any macros to populate a redundant field.
Related
I am designing a reward system for my game. I have a table called VirtualItem (VI) (key, display_name), the data contained could be (gd, gold), (dm,diomond). Then I have a Reward table (id, reward_items,etc)
Currently reward_items are a json array of VIs: [[{key: dm, count:5},{key:gd, count10]].There is a web portal allowing user to CRUD reward_items.
My question is, should I use the current flat structure, or add another layer in between and use reference in reward_items instead? Something like reward_items: set_id(referring VirtualItemSet table).
Apparently, using flat structure(json array) will make the query easy. But I probably also need to put dislay_name inside the JSON as well. In addition, when VI changes, its hard to update reward_items.
Using relationship makes the db schema more complex, and make backend operation on CRUDs operation of reward_items complicated as well.(need to create VirtualItemSet item on the fly etc). It also make query more complicated. But it will support dynamic change of VI.
Whats your opinion on this? Or there is a better database for this type of senario?
Thanks,
Chen
As you notice: If you use flat column you can't make sql join and keep data consistency by database for foreign keys. In my practice this decision always make problems in future. So i think better don't use flat columns.
I'm and intern and I've been tasked with something I'm pretty unfamiliar with. My manager has requested I create a simple MySQL database using data from an Excel file(s) and I have no idea where to start. I would normally ask someone here for help but everyone seems to be really busy. Basically, the purpose of the database is to see what different object-groups relate to one another so as to keep things standardized. Trying not to go into detail about things not really relevant.
I was asked to first design a schema for the database and then I would get an update on how to implement it. Would I just start by writing queries to create tables? I'm assuming I would need to convert the Excel files to .csv, how do I read this data and send it to the correct table based on Object Type (an attribute of each object, represented in a column)?
I don't want to ask too much right now, but if someone could help me understand what I need to do to get started I would really appreciate it.
Look at the column headers in your spread sheet.
Decide which columns relate to Objects and which columns relate to Groups
The columns that relate to just Objects will become your field names for the Object table. Give this table an ID field so you can uniquely identify each Object.
The columns that relate to the Groups will become field names for a Group table. Give this table an ID field so you can uniquely identify each Group.
Think about if an Object can be in more than one Group - if so you will probably need an Object-Group table. This table would most likely contain an ObjectID and a GroupID.
I'm working on a project to make a digital form of this paper
this paper (can't post image)
and the data will displayed on a Web in a simple table view. There will be NO altering, deleting, updating. It's just displaying (via SELECT * of course) the data inputted.
The data will be inserted via android app and stored in a single table which has 30 columns in mysql.
and the question is, is it a good idea if i use a single table? because i think there will be no complex operation in the sql.
and the other question is, am i violating some rules for this method?
I need your opinion. thanks.
It's totally ok to use only one table, if that suits your needs. What you can do to make the database a little bit 'smarter' is add new tables for attributes in your paper that will be repeated. So, for example, the Soil Type could be another table where there are two columns, ID and Description, and you will use it as a foreign key in each record in the main table. You need this if you want your database to be in 3NF.
To sum up, yes you can have one table if that's all you need. However, adding more tables might help save some space and make your database more flexible. It's up to you to decide! :)
Within my database i have 3 different tables for different members. When saving the members details i use a form to save the members all to the same table but i would like to save them to a specific table depending on their details. for example if a member has registered with their school email i would like them to be saved within the student table, if they have used a freemail email address to be saved in the freemail table etc
Would this be run as a query or sorting the one table using if statements?
You probably should not have three tables, just a field that defines the member type. You may wish to read Fundamentals of Relational Database Design.
If you really insist on having three tables, even though it is likely to cause ever more tangled scenarios, you will either have to use VBA to gather the data from an unbound form and then fill it into the appropriate table, or ask the user which table they wish to update before you start and set up the form for that table.
It depends on your development environment. You can either change the switch to an If clause at business level or you can implement it as a database procedure. It's up to you.
http://msdn.microsoft.com/en-us/library/aa933214(v=sql.80).aspx explains how to use If clause in database
I have a form with about 500+ fields (it's a 10 page form, different data types). Can you guys please advise me on the best way to store the data from the form? I can create 500 fields in multiple, logically divided tables but that seems a lot (or maybe that's the best way?!) since I have a few of these forms. I am looking into serializing the data and storing in longtext mysql field. That will have its drawbacks (the one I am thinking of is if the customer wants to search individual fields in the future) but it does seem like a pretty fast solution. I will appreciate if you would share you experience with a similar situation.
Presumibly you dont expect the user to fill the form in in a single sitting! So you will need some sort of work flow to store drafts and amend previous copies etc.
Also assuming some parts of the form are optional.
You could either define a set of database tables with a master table to track status, user name etc, and a child table for each optional part of the form.
Or you could define an XML schema which contains all the possible fields in the form etc plus some status information.
If you always process the entire form and dont want to search through your collection of forms then the XML soiution is slightly better as there are some nifty tricks for moving data from XML to HTML forms and back again. If you need to search based on values inside the form then the SQL based solution is preferable.
You may need 500 columns - unless they can be placed in other tables. It can be hard to tell without seeing your requirements.
Serialising it would make one of the advantages of using a database impossible - querying against certain column values.
create table profile_details (
user_id number,
field_name varchar,
field_value varchar
);
Now you are not only not limited by number of fields, you also pretty free to add and remove them as you keep developing and maintaining your app.
select firstname, lastname, zipcode
from profiles p
join profile_details d1 on (p.user_id=d1.user_id)
join profile_details d2 on (p.user_id=d2.user_id)
where d1.field_name='hobby' and d1.field_value='fishing'
and d2.field_name='income' and d2.field_value>cast(250000 as number);