Having big data for different departments, require to do monthly update on them.
Each time when the data is updated I need to sort them to different departments.
You need to search stackoverflow.com. There are multiple questions of similar types which have been answered.
Besides you can also try to record a macro and edit it to suit your needs.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am interested in learning SQL. I span up a Server 2019 and installed SQL Express on it. I am currently going through a basic SQL course on Codecademy but figured it would be a lot better to practice with some hands on. I came up with an idea to create a database to track my monthly bills and finances. Once I have enough data then I can leverage some graphing tools to visually present the data.
Has anyone done something similar before? Any suggestions as how I should design the database/tables? Keep in mind that my SQL knowledge is still very limited.
Thanks in advance!
This is a very broad question and nobody can give a definitive answer.
I agree with your approach of trying it yourself in your own situation - that's a definite thumbs-up from me (indeed, when we get new employees, this is one of the best traits when reviewing them). So many times people learn so much by 'getting their hands dirty' so to speak (e.g., going on and trying it themselves).
However, I suggest starting with the examples they have to get the general concepts down - the usually choose at least decent examples.
Alternatively though, you could give it a shot. Just be prepared to be wrong and start again. But don't worry - in terms of value, having a shot and getting it wrong is worth much more than reading something and only half-understanding it.
If you are familiar with spreadsheets, I suggest
Imagine how you would keep this on spreadsheets e.g., one sheet with bills that are due, and one sheet with your payments
Each one of those sheets would represent a table in your database.
If you pay all your bills with one payment only (e.g., no installments), then it would be easier to do it with one spreadsheet (e.g., just listing all the bills on the left side, and their payment information on the right). In this case it may not be the best case for teaching yourself databases. On the other hand, if you do pay by installments, then this could be useful.
The big difference difference in approach, is that in databases, the rows are not inherently sorted. Instead, you typically give the rows an identifier (e.g., Bill_ID, or Payment_ID). And then the tables are linked e.g., for a given row in Payment table, you'd also include the Bill_ID to represent which bill the payment was for.
Update: More examples
To choose a relevant thing to try on databases, I suggest choosing things that are related to each other, but are separate from each other (e.g., not linked 1-to-1).
In the bills/payments above, if you paid each bill with one payment, they didn't need to be on separate tables. However, you could try other things e.g.,
You live in a sharehouse where people pay for various things in a 'kitty' sysem (e.g., on each person's payday, they put in the amount they owe). In this case you may have a Bill table (which includes how it is split up, and when it was paid), and Person_Payments table which includes when people put money into the kitty
You have a family with kids and chores. You have a Kids table (with their name, etc), a Chores table (listing chores and how much they are worth in pocket money) and then a Kids_Chores table listing the Kid_ID, Chore_ID and date. Whenever they do a chore it goes into Kids_Chores and that is used to determine their pocket money.
You play various computer games and you want to track your win rate on them over time. You have one table for Game (with info about your user ID, etc), one for Game_Mode (which indicates, for a given game, what mode you were playing e.g., casual vs league, easy vs hard), then one for Game_Stats recording the date you played, the game and game_mode, and the number of games and number of wins.
I have two excel tables. One is a list of names with a calendar that tracks number of days traveled and puts it in percentage. The other table shows proposed travel schedules for the same list of people but in a different format. I have to manually find their percentage in table 1 and input them to the second table for presentations. I want to develop something that reads the names in both tables and can copy their travel time percentage into the second chart. Maybe adding it in the cell or to a blank row below. I have been unable to find any previous threads relating to this. I am new to programing and do not know if this can be done in VBA macro for excel. Does anyone know what functions I could use to accomplish this?
The quickest way is to use powerpivot. You'll have to look at your version of excel to see how to access it. For instance, powerpivot is included and preset in excel 2016, and is a free add-on you'll need to download for excel 2010.
You can uplaod both those tables into the powerpivot model, define the relationship between the two tables (as simple as dragging the relationships in a diagram view). Then you literally have a pivot table that connects both and you can create a measure that does what you're saying. The plus is that there's so much more you can do!
Hearing how your data is set up if you run through a powerpivot table tutorial you might even rethink your data set-up. The advantage is you don't need to learn vba just learn to apply your current and new excel skills. A good starting point is here:
https://msdn.microsoft.com/en-us/library/gg413497(v=sql.110).aspx
There are also 5 min youtube clips that'll give you a good idea of what else you can do with it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Ok ok I know you probably all going to kill me for asking this, however I got into an friendly programmer argument with a co-worker about one of our database tables and he asked a question which I know the answer to but I couldn't explain it is the better way.
I will simplify the situation for the simplicity of the question, We have a fairly large table of people / users. Now amongst other data being stored the data in question is as follows: we have a simNumber, cellNumber and the ipAddress of that sim.
Now I am saying that we should make a table lets call it SimTable and put those 3 entries in the sim table, and then put a FK in the UsersTable linking the two. Why? Because that's what I have always been taught NORMALISE your tables!!! Ok so all is good in that regard.
But now my friend says to me yes, but now when you want to query a users phone number, SQL now has to go and:
search for the user
search for the sim fk
search for the correct sim row in the sim database
get the phone number
Now when I go and request 10000 users phone numbers, the number of operations done seriously grows in size.
Vs the other approach
search for the user
find the phone number
Now the argument is purely performance based. As much as I understand why we do normalize the data (to remove redundant data, maintainability, make changes to data in one table which propagate up etc.. ) It does appear to me that the approach with the data in one table will be faster or will at least less tasks/ operations to give me the data I want?
So what is the case in this situation? I do hope that I have not asked anything insanely silly , it is early in the morning so do forgive me if im not thinking clearly
The technology involved in MS SQL server 2012
[EDIT]
This article below also touches on some pf the concepts I have mentioned above
http://databases.about.com/od/specificproducts/a/Should-I-Normalize-My-Database.htm
The goal of normalization is not performance. The goal is to model your data correctly with minimum redundancy so you avoid data anomalies.
Say for example two users share the same phone. If you store the phones in the user table, you'd have sim number, IP address, and cell number stored one each user's row.
Then you change the IP address on one row but not the other. How can one sim number have two IP addresses? Is that even valid? Which one is correct? How would you fix such discrepancies? How would you even detect them?
There are times when denormalization is worthwhile, if you really need to optimize data access for one query that you run very frequently. But denormalization comes at a cost, so be prepared to commit yourself to a lot more manual work to take responsibility for data integrity. More code, more testing, more cleanup tasks. Do those count when considering "performance" of the project overall?
Re comments:
I agree with #JoelBrown, as soon as you implement your first case of denormalization, you compromise on data integrity.
I'll expand on what Joel mentions as "well-considered." Denormalization benefits specific queries. So you need to know which queries you have in your app, and which ones you need to optimize for. Do this conservatively, because while denormalization can help a specific query, it harms performance for all other uses of the same data. So you need to know whether you need to query the data in different ways.
Example: suppose you are designing a database for StackOverflow, and you want to support tags for questions. Each question can have a number of tags, and each tag can apply to many questions. The normalized way to design this is to create a third table, pairing questions with tags. That's the physical data model for a many-to-many relationship:
Questions ----<- QuestionsTagged ->---- Tags
But you figure you don't want to do the join to get tags for a given question, so you put tags into a comma-separated string in the questions table. This makes it quicker to query a given question and its associated tags.
But what if you also want to query for one specific tag and find its related questions? If you use the normalized design, it's simply a query against the many-to-many table, but on the tag column.
But if you denormalize by storing tags as a comma-separated list in the Questions table, you'd have to search for tags as substrings within that comma-separated list. Searching for substrings can't be indexed with a standard B-tree style index, and therefore searching for related questions becomes a costly table-scan. It's also more complex and inefficient to insert and delete a tag, or to apply constraints like uniqueness or foreign keys.
That's what I mean by denormalization making an improvement for one type of query at the expense of other uses of the data. That's why it's a good idea to start out with everything in normal form, and then refactor to denormalized designs later on a case by case basis as your bottlenecks reveal themselves.
This goes back to old wisdom:
"Premature optimization is the root of all evil" -- Donald Knuth
In other words, don't denormalize until you can demonstrate during load testing that (a) it makes a real improvement to performance that justifies the loss of data integrity, and (b) it does not degrade performance of other cases unacceptably.
It sounds like you already understand the benefits of normalisation, so I won't cover these.
There are a couple of considerations here:
1. Does a user always have one and only phone number?
If so, then it is still normalised to add these to the user table. However, if the user can have either no phone number or multiple phone numbers, then the phone details should be held in a seperate table.
Assuming you have these in seperate tables, but after conducting performance tests you found that joining on these 2 tables was having a significant effect on performance, then you may choose to deliberately denormalise the tables for performance gains.
Others have already provided some good points and you may also want to take a look at this.
I'd just like to mention one more aspect that is often overlooked: I/O tends to be the greatest component of the cost of most queries, and denormalization generally increases the storage size of data, therefore making the DBMS cache "smaller".
If your normalized database fits into cache and denormalized doesn't, you may actually observe a performance decrease for the latter.
And you won't be able to spot that in development, unless you actually have the amount of data that is similar to production. This is one of many reasons why you should never, ever denormalize without solid measurements (on representative amounts of data) to justify it.
I have a table consisting of three columns; the first is an ID, the second describes the activity assigned to that ID and the third defines the category that the activity falls into. I have a combo box, which contains a list of all of the categories lifted from another table. I would like to have a second combo box, which, on selection of a specific category, allows the user to pick an activity from that category.
My knowledge of access and databases is quite limited, so any help would be appreciated.
This is a fairly complex thing to actually do, but it is doable. If you're dead set on it, it will require learning a bit of both VBA and SQL. You essentially need to write VBA code that will first define SQL queries as a string based on your choice in the comboboxes and then passes that string as the source of each following combobox.
If your experience with access and databases is limited as you say it is, you may want to opt for a simpler solution for the time being. If you want to see more in detail how something like this would work check out http://www.fontstuff.com/access/acctut15.htm
There is a walkthrough here at MSDN on synchronizing two comboboxes. It is a common feature so internet searching will locate other similar examples.
Suppose you have an Excel workbook and you need to write a macro that takes inputs from many different cell references, and updates values at many different cell references, how do you keep the code neat and maintainable?
It would be helpful to know:
best practices
useful tricks
unavoidable difficulties
necessary trade offs
If there are links to existing guides or discussions that would be helpful too. I haven't been able to find any.
Edit: I found http://www.eusprig.org/best-practice.htm very useful - from the European Spreadsheet Risk Interest Group (EuSPRIG).
It slightly depends om what the macro is going to do, but I use 'calculation' sheets, where I gather together the data I need for the macro, and output the results there.
I tend to do this do in defined ranges.
The result data can then be referenced from elsewhere.
Tricks: One thing I do is to create a visual 'check off' for each piece of input data as it's used. This just enables me to make sure that all the data I thought I was going to use, I have used.
Following Naming criteria is better solution , irrespictve of language.
in_name_range, out_name_range
in_num_range, out_num_range
Check points and adding watch , would surely help.
If you are going for modularity, Take care about updated ranges
(As you can't return more than one value at a time better write ranges in some predefined order in some sheet. This works for me.)