What is the best memory data structure to hold a grid ? By grid i mean a rectangular table with rows and columns, where the entries are not single values, but can hold any information.

Example: an availability "calendar", where i want to show room types as row headers (variable number), and dates as column headers (fixed, limited to 2 weeks at a time); and the intersaction being all information about the particular cell (e.g. booked, available, guest names, etc).

Thanks for any pointers.

 

If your language supports arrays, then that is probably going to be best. Some languages will allow you to define a data structure as well. Your programming manual is your friend.

 

A relational database would be a good way to store this data. It would automatically manage saving the information to disk, if you need it stored more permanantly.

You can create columns of numbers, text, timestamps, then you can add, delete, modify, select the rows of stored data.

You can download relational databases such as MySQL or Postgres that could do this job.

 

Thanks beenthere,davebee for your replies.

A relational database would be a good way to store this data.

That's a given, i am assuming that. The question was really about an in-memory data structure that can store the information in transition, before it is displayed on a webpage.

The language i am using is C#. I was trying to avoid arrays, e.g. a 2-dim array probably can do the job, but its indexes are integers and cumbersome to deal with. e.g. rather than use ArrayOfObjects[x,y] , i wanted something more OO and strongly-typed such as AvailabilityCal<RoomTypes,Weekdays>, maybe i have to write my own object, but wasn't sure how to approach it.

 

It seems to me that a 2-D array would serve well, but maybe a better choice would be C++. With that language, your array wouldn't be Object-based as all arrays are in C#. You could define your own class or struct to hold whatever information you want for a given room, and then create your two-dimensional array based on that type. The array's underlying data type would be of your design, so the array would be strongly-typed.

Also, I don't understand your objection to integer indexes. The mappings between room types and the row headers, and between a two-week span of dates and the column headers are very simple. If you understand arrays at all, indexes are not at all cumbersome to work with.

 

If you'll be using a relational database then what is the advantage of copying your data to, then manipulating it in an in-memory array? Your data is already stored in an array-like structure with plenty of available commands for manipulating and formatting it.

MySQL, to pick one example, lets you generate in-memory, temporary tables on the fly if you want a fast area to stage and process data into a resultset.

I don't know the details of your needs, but in general, it's usually straightforward to use SQL to generate a resultset ordered and formatted just as it's needed for display, then you can pull up the resultset row by row and generate the final output text suitable for writing to an html file, if that's where the data's going.

 

2-D array would serve well... Also, I don't understand your objection to integer indexes.

My initial objection to integer indexes is that i didn't want to play around with the mappings, if a better structure was available (e.g. like a Dictionary, where given a typed-key, return a typed-value; problem is dictionary is 1- dimensional, wish there was a 'two-dimensional' dictionary).

Also i wanted to grow my rows dynamically, but can live without this since i will know my room types in advance (hence my array size)

Looks like i will go the 2-D array way, you convinced me in the absence of a better structure.

Thanks for your input.

 

If you'll be using a relational database then what is the advantage of copying your data to, then manipulating it in an in-memory array? ... you can pull up the resultset row by row and generate the final output text suitable for writing to an html file, if that's where the data's going.

Just trying to do it in an object-oriented way, with separation of layers (presentation, domain objects, data), where the presentation (i.e. the html part) does not need to know about Sql or datasources.

Thanks for your input just the same.

 

As far as your objection about indexes, you could use an enumerated type to represent the room types, and another enumeration to represent each day in the two-week period. Then you could access the information about a particular room on a particular day something like this: RoomInfo(RED_ROOM, TUESDAY1).
Since you asked for a timeline of two weeks, you will of course have two of each dayname. The enumeration values are integers that you can define as appropriate.