i want two arrays first one of all subjects and the second of all degrees which study in all universities (all over the world)
But a big problem is that i dont know how many subjects and how many
degree are there.? (in all over the world)
I just want two array the remaining logic i have made already.
All subject array list must be like.
$subject[0]=>'Computer Science',
$subject[1]=>'Mathematics',
$subject[2]=>'Engineering',
$subject[3]=>'Physics',
...
And secondly array of all degrees must be like.
$degree[0]=>'BS',
$degree[1]=>'MS',
$degree[2]=>'BA',
$degree[3]=>'MA',
...
Keep in mind that
**
I dont know how many subjects and how
many degree are there.? (in all over
the world)..
**
I just want these two categories in two individual array & thats all....
Could any one help me.?
Thanks.
Your problem appears to be twofold; there's the issue of getting hold of the data, and the issue of storing it in a manner which allows effective retrieval and use.
Obtaining the data is likely to be your biggest problem; you're literally asking for information about every institution in the world (or at least, as many as you can get). The available qualifications and nomenclature varies widely between different countries, and the list of courses at any given institution is going to be vast.
Finding a single decent, machine-readable source for this information is probably not going to happen. Your best bet would be to try and find multiple sources, but I'm struggling to think of any really good ones off the top of my head, and Google isn't looking too promising. You could attempt to scrape data from sites such as the Universities and Colleges Admissions Service (the UK body which basically catalogues higher education) - I've linked to their "course list" pages. Whether similar bodies (and similar data sets) exist for other regions, I've no idea.
The second problem is quite straightforward; you're going to have a ton of data, so you'll need to store it in a database. Then again, it's not that straightforward. Presumably, you want to catalogue courses by institution, and institutions by country, so make sure you normalise the data a little. You'll probably need to do some work to identify equivalent degree grades (as mentioned above) between different countries.
I don't understand exactly your question. But if you're trying to fetch records from your database and deposit 'em into an array, mysql_fetch_array() is what you need: http://php.net/mysql_fetch_array
As far as i could understand your question, you need to know how to store subjects in an array. See arrays in php. If you are looking for storing your subjects in database then see php and mysql tutorial. Because you want to store unknown number of subjects and degrees, don't use something like:
$subject[0]=>'Computer Science',
$subject[1]=>'Mathematics',
$subject[2]=>'Engineering',
$subject[3]=>'Physics',
Instead use:
$subject[]=>'Computer Science',
$subject[]=>'Mathematics',
$subject[]=>'Engineering',
$subject[]=>'Physics',
This will add subjects to the array without your puting index manually.
Related
There's a very similar question: Modeling products with vastly different sets of needed-to-know information and linking them to lineitems? But I can't find an answer that help me;
Someone at the above Q&A points to designing database to hold different metadata information , which has a fantastic accepted answer, but since search function is explicitly needed in my program, I don't want performance to be compromised.
I'm a "technician" that uses PHP + Oracle to keep track of the selling progress of our company and generate reports. Our workflow generally looks like this:
Marketing guys provides prepared data-set to my system;
Frontline staffs (sales) mark progress on my system;
Anyone can search results in the system;
I generate reports back to marketing guys.
The problem:
Many columns of data-sets are the same (or can be considered the same), like these:
account|customer_name|gender|location|program_segment|...
But the marketing dept. like coming up new ideas (and abandoning existing ones), so each "sales program (campaign)" may has its own data, e.g.
For program 1, they may contain:
...|prev_coupon_code|last_usage_amount|...
For program 2, however, they may contain:
...|is_in_plan_1|is_in_plan_2|...
You got the idea.
Unsuccessful attempts:
In order to hold all data, I used to use a "long enough" table that has all possible properties (columns), and leave blank/unnecessary properties NULL.
But now I feel that it will never be "long enough", as there're too many "properties" and even more "sales focusing point": I drafted a 41 column table for a new version of the system and suddenly they proposed a new program that has information that can't fit.
Someone suggested me to create "dummy columns" in the table and "remember" different meaning of them in frontend. This can work for several datatypes, like NUMBER(1) for Y/N, DATE, etc., but when talking about VARCHAR2, I'm not sure how many of that is enough...plus this makes the table look "dirty".
Question:
Frustrated, I'm now seriously considering using different tables for different programs, and use UNION clause to generate big report in case they're asked "how are we selling this month/season/year?"
Technically, is this a good practice? Should I implement it?
Edit #1:
To clarify, one "sales program" will generally be running for a few months before it got abandoned, and there'll be at least one data-set per month for each running program.
And there can be more than one program running at the same time.
Edit #2:
Those "program-specified" columns are of various number: one program may need 10, while another may only need 1.
This is one of those situations where there is no right answer, just a choice of kludges.
I would plump for using an XMLType to hold the transient data structures. XML gives us the ability to have defined schemas for each plan, but using an XMLType obviates the need to change the database itself. We can index XPath queries so the performance can still be good. Find out more.
The one problem is that writing queries against XML is a bit of a pfaff, but I think awkward queries will be an issue for whichever apporach you take.
You may or may not be aware that it is possible to index the contents of a character LOB in Oracle. You might look up Oracle Intermedia / multimedia (depends on your version) and talk to your DBAs to see if it is available to you.
This would make it possible to create a common structure for common data items - eg campaign, start_date, end_date, &c but then to dump your spreadsheet/xml data/csv file into a CLOB field.
The plain-text indexing is not as hard as it first sounds and it is very cute indeed.
If you go down the different table path you will forever be changing code to meet the changing columns etc.
One option would be to have 2 additional columns 'campaign_name', 'campaign_value' and put the column name they send you in the NAME column and the value in the value column.
So,
account|customer_name|.....|campaign_name|campaign_value
'ACC001'|'Frank Burns'|........|'prev_coupon_code'|[value of prev_coupon_code
and then in your 2nd example:
account|customer_name|.....|campaign_name|campaign_value
'ACC001'|'Frank Burns'|........|'is_in_plan_1'|[value of is_in_plan_1
Update - yes, this would involve changing the grain of the table so you would add a set of data for each of the campaigns.
The import would be a little different in that you'd UNION the records for each of the column names that appear on there, and the reporting would need to take into account the grain change.
It sounds like a complete waste of space, but if these are Excel sheets then performance shouldn't matter. If it did you would need to split the tables into
- campaigns, accounts, accounts_campaigns
On my current job, I successfully use following system for 2 years.
You have one main table, let's say 'report', that consist of common columns for all kind of reports.
id - primary, auto_increment.
name - name of the report.
Then, for each specific report, you have another table, called something like "report_marketing". There you have report_id column, that is foreign key to first main table. And here you add all specific columns for this specific report.
To get results, you simply use LEFT JOIN.
If some reports share some columns from 2 or more tables, you can always join more than one column.
Here is example of query you might have:
SELECT report.name, report_marketing.ammount FROM report WHERE report.type = 'M'
LEFT JOIN report_marketing ON report_marketing.report_id = report.id;
How should I store States and Countries?
Option 1) I could create a database table called states, and have 'id', 'state', and 'state_abbr'. I could then reference that by 'id' in the users table.
Option 2) I could create a PHP array and use that to populate the states drop down menu, and avoid querying the database altogether. The key for the array would be the value inserted in the database for that user.
States don't change, and so the data should be static. What's the best way to store this information and why? Wouldn't a PHP array be faster? Why does it seem like the database is the best way to store it then?
Thoughts?
A wise database designer once told me, "Everything you know about state codes is wrong."
These are two-letter codes, not abbreviations. (The abbreviation for California is "Calif.", and the abbreviation for Ohio is "Ohio".)
There are more than 50 of them.
Not all of the two-letter codes refer to states. They also refer to "possessions" like "Federated States of Micronesia" and "Palau".
They're not unique. One two-letter code, AE, refers to four different military "states" (Armed Forces Europe, Armed Forces Canada, Armed Forces Middle East, and Armed Forces Africa).
Military "state" codes may change as troop strength changes. Send a few hundred thousand troops into Africa, and you're likely to see the code for Armed Forces Africa change from "AE" to "AF".
There are a dozen or so territories that aren't yet in this list. Some of these are of strategic interest (Wake Island, Midway Islands, etc.), and their status could easily change.
Given that you're not likely to know all these things about such a common thing as USPS state codes, it just makes more sense to store them in a table. Tables are easier to maintain at run time than a PHP array is.
Because the database is the best way to store it.
What if next year your company decides to go international?
So now you need countries, and a dependent dropdown for states.
So you need to add europe, then africa.. Thats a TON of countries, along with a ton of states. You will need one big array.
Then your boss wants a report by country.
Much easier to manage if you have it all in a database.
I know this is old, but in case anyone else is wondering the same thing. I am currently in the process of designing an application, and to ensure data integrity, I wanted to create a country and state table. I also have cities, but I'm going let the users populate that I think as they enter addresses.
Now i say that, because at some point, I do hope my application will go international.
So, my current DB for countries has 249 records. (I removed some that don't have a population)
States, on the other hand was a bit harder cause not every country refers to them as states. (There are states, provinces, departments, parishes, Territories, districts, regions, and maybe some others.) But that table contains 3438 records for now.
Now i may vary well be wasting my time researching this information, as there may even be a database of this stuff online that i could simply reference with an API of some sort, but for now i got my info from something called the iso 3166 (-1 for countries -2 for states. (I believe))
So the reality is, I will likely never see business from some of these countries, but they are there for now.
I've also created a table for formatting currency values properly. That's also a bit difficult as I've only fond the needed information for a handful.
But DB design does seem to get a little complicated when you have to account for the differences in information in various countries.
But to ultimately answer your question, if you are solely doing business in the US, hard coding or using a database would work, but States do change. Although it's been a while since we've added new states, it does happen, and may happen again soon. So a DB would be easier to manage I would think for any changes. Plus, if you decide to display additional information associated with the state, all you'd have to do is add some columns and all your references would display that information.
My view is to not have data hard coded in the code, but I'm not a professional. Even things that you thought would never change like gender, has proven that it too can change with all these Trans terms people are coming up with these days.
I am wanting to do something similar to this:
http://www.dimarzio.com/pickup-picker
My question involves the concept rather than any specific code on how to execute this.
For example, we are selling violins and we want the user to input info about their playing style, and give them the three best violins based on their entry. This is the data I've been given:
So if the user inputs Expert, Hard, Rock, and Dark I will get data sets of violins consisting of: Cannon, Soil, Ysaye, K.Joseph, Heifetz // Cannon, Kreisler, Soil, Heifetz // Kreisler, Diable, Vieuxtemps // Cannon, Diable, Plowden
Out of those I need to output to the user the three best choices for them. Cannon is listed in 3 out of the 4, so that has to be #1. Now there are three more violins that match two of the four criteria. The Soil, Kriesler and Diable. In order to drill that down to two choices, I would think the questions would have to be ranked according to importance. For instance Tone is most important, followed by bowing style, musical genre, and skill level. Based on that ranking, the program should choose the Diable and Kreisler.
I am not entirely sure how to approach this. Since this data will not change frequently, should this even get the database involved? Should the info just be stored in a multi-dimensional array? Once the data is in an array, whether from the DB or not, how should I go about programming the logic to examine the arrays in order of importance and grab the violins that are most relevant?
Any help is much appreciated! I figured this was going to be easy, until I actually started thinking about it!
To me this sounds like a sorting problem. I don't know anything about violins so I'm unable to absorb much from your example, but anyway...
You're probably familiar with how a database sorts across multiple columns. If I said order by firstname, lastname, phone it would compare the firstnames, and only if theres a tie, would it then compare the last names, and again if there's a tie, then it would compare the phone numbers.
Once sorted, you pick the top N entries and display.
You can do custom sorting like this in php code too. For example, you would want to order by num occurances in a list, tone, bowing style, etc...
Thats the gist of it. I would store it in a database merely because its data and for the most part, its a great place to keep it. Plenty of import export and other data management, viewing, editing and other functionality freebies come with using a database.
If you need some sample code that mimics the database order by clause, I can dig some up I know I have somewhere.
We have a start up company that solves the issue you are outlining. Basically we have created a semantically enabled product selector which guides users through a selection process to find a product or a solution.
Although we have designed our product for a different market sector (not vioins), I think it would help to solve the issue you describe.
The data is hosted on Amazon AWS and we have built an API so the product selector can be incorporated into iPhone apps, Android apps, websites etc.
If you want, our website www.productworld.com where you will get my contact details.
well, im really new to mysql, and i have no idea to do what i am intending to, or atleast not the efficient way.
i have to make a database that will hold people's information
within it every person has 3 courses to pass(courses as in educational courses) lets say its stage 1, 2 and 3, they cannot start course 2 without completing course 1
every course has 10 tests, they have the same name (eg. there is a test called example1 in course1 and also a test called example1 in course2, but its more difficult)
there aren't grades, just passed or failed
and lastly they are permitted into taking each test 3 times, i want to store the date(every try) and also who was the applier of the exam(every try), the names of the "teachers" are on a table
It is not a matter of mysql or php.
You should learn about Database Modelling.
And then use any of these tools (I like DB Designer for modelling)
Then you should learn how to integrate PHP and MySQL
Try Sakila database created by mySql, this is an example database used for training. You'll learn a few tricks from there, quite useful before creating your own database or maybe even before reading some books or the theme.
In additon to patricio's answer (which I consider valuable and good pointers). Take what you have written above and extend it. Find the key works in your description (i expect this will include people, course, test ...). For each key word identify all details you need to hold.
E.g. "I have to make a database that will hold peoples information" And for people I need to know ... maybe first name, last name, data of birth, employee number, etc. What ever details of a person is relevant to you. List them in a spreedsheet or document. Repeat this for each key word.
Then consider items you need to know to run the system, your last bullet point heads in this direction. Identify any new key words from that and then details you need to know about those key words.
Take your list of details and normalise it. As a general rule of thumb aim for 3rd normal form. In most cases it appears to be a workable compromise between higher levels of normalisation and not doing it. Maybe one of those 80/20 rules where by with 20% of the effort it takes to get there (as opposed to normalising to 6th normal form) you get 80% of the benefit of normalising.
Put together a proposal and feel free to come back for us to critique it if you want.
I am currently building a codeigniter application that handles a specific type of mammal. When a user is adding a new record (mammal), they are given lists of 'breed types', 'genders', etc. Those are stored in separate database tables.
Currently, to get these, I have separate functions such as:
$this->Mammal->get_list_of_breeds()
$this->Mammal->get_list_of_genders()
Each of these calls a query, there may be up to 7 or 8 more different lookups for me to query. Does anyone know if this will significantly slow down my application or cause too many queries on the database. For the most part, the max number of records in any individual table is under 300 records.
Is there a better way I can be doing this by consolidating the queries into a single function and using php to split the lookup fields?
Any ideas or thoughts are greatly appreciated.
One idea is to take some of the smaller sets of options and put them in arrays, especially if they cannot be changed by the user. Gender, for example, could probably just be in an array. As far as I know, there are only two options. If there are any other similar option sets you could make those arrays too.
But, even 300 records is not a huge amount of data. I take it you aren't building the next Facebook, so just making several clean queries to get the options you need probably won't be a big deal.
Personally, I wouldn't put it all in one table. Big generic tables just seem kind of hokey, and you would still be getting the same amount of data. You could have separate tables and accomplish the same thing by UNIONing the queries.
As you commented yourself, yes indeed you should put everything into one table...
So you'd have a table called mammals
And then you'd have the fields: gender, breeds etc...
Now this is a lot easier when programming in php since now you can do one query and then display everything, like this:
$query="SELECT * FROM `mammals`";
$query_exec=mysql_query($query);
while($result=mysql_fetch_array($query_exec))
{
print "gender: ".$result['gender']." breed: ".$result['breed'];
}
Little explanation:
The query gets everything from the table called mammals
Then the while just continues as long as there are still results in the array
The fetch array puts the data in the variable and every field can be read by $result[]
I know this is not a very clear explanation, but my mind also isn't the cleares at this late hour :/