How to make table from two dimension array

Questions about the MySQL, PostgreSQL, and most other databases, as well as using it with PHP can be asked here.

Moderator: General Moderators

Post Reply
tanvirtonu
Forum Commoner
Posts: 35
Joined: Wed Oct 17, 2007 9:15 am

How to make table from two dimension array

Post by tanvirtonu »

I have a report like the following- [the expenses of each item under the item heading is recorded for a date of a particular month]. I cant format the report as i want but u can realize it
  • Jan 2007

    Fields/Months - 1 3 4 5 . . . . . 30 31

    labor(Total-$)
    Male 4
    Female 8

    Staff Salary($) 4
    Jim
    Jerry 6
    John 5

    Coal($)
    Transport 5
    David(Driver) 5
    Johnson 9

    .......so on
Now could anybody tell me how to make my database table for this report. This looks like a 2 dimension array of records. Should I build a table for each dimension like one for labor including the male and female as fields of that table. OR all fields in a single table including all those fields. As u can see each item is(or can be) recorded in a particular date of a month. It means record can be inserted at any date of a month. In this case if I make a single table, how can I insert record several times in a same month. It is a little confusing to me.Pls anybody tell me how to make table out of SUCH two dimension array.There must be a conventional way to do this.
[/list]
User avatar
califdon
Jack of Zircons
Posts: 4484
Joined: Thu Nov 09, 2006 8:30 pm
Location: California, USA

Post by califdon »

I don't understand what you are trying to do at all.

But there is an accepted way to design relational databases. A database can be considered a model of some part of the real world. The real world (or the part you are modeling) consists of entities (people, objects, events, transactions, etc.) that have properties. You should always begin by identifying what entities you need to represent in your database. If your thinking is fuzzy about the entities, you are guaranteed to fail at designing a suitable database. Don't confuse this step with deciding whether a certain piece of data should be in one table or another, just concentrate on getting clear definitions of the entities you need. Write down the definitions so you can review them over and over (if it's somewhat complicated). Only AFTER you have rock-solid definitions of your entities should you even begin to think about properties of each entity. This second step should consist of asking yourself, over and over, "What properties of this entity must I be concerned with?" When you have finished this analysis, you have your design: each entity is a table. Each property is a field in the table. You might need some other linking tables, but the hard part (and the important part!) is properly identifying the entities and properties.

The reason that I don't understand what you are trying to do is that what you showed us doesn't appear to me to have any coherent entities. It seems to be based on some concept of what some particular report should look like. That's absolutely the worst possible way to approach the design of a database.

Please understand, I'm not criticizing you, I'm trying to help you understand some vital parts of database design.
Post Reply