Need Suggestions for a Data Structure or Style to Store my Data

S

svet-am

Supreme [H]ardness
Joined
Jan 6, 2003
Messages
5,146
Preface: I used to do web development a lot more than I do now, but that was in the days before AJAX. For the project I'm currently working on, I'm teaching myself AJAX so forgive any glaring misunderstandings or stupidity.


In my normal work, I'm a PCB designer but I've been tasked with helping (read: doing all the work) a team re-vamp an internal search tool that we use.

The scope of the project is to have an iGoogle-style drag and drop interface where the "widgets" in the drag-and-drop interface are all independent search terms for a SQL query. Taken together, they all form a complete search query that the user wants to perform.

My drag-and-drop interface is based on a series of four (hard-coded) columns that are basically just unordered lists (UL). The "widgets" are CSS-styled list items (LI). The AJAX JavaScript allows me to drag-and-drop the widgets around into any given order or orientation.

Right now, I have the drag-and-drop functionality working and I also have the ability for users to add/remove widgets to suit the needs of their own query.

The final scope of the project is to do two things:

1) allow the user to save their query for later user
2) allow the user to share their query with other users of the system

Fundamentally, I understand this concept but I'm struggling with the most efficient way to store this data because I need to preserve not only the query as a whole but also the location of the various "widgets" inside the drag-and-drop interface.

Any advice on a good data structure or design practice to accommodate what I need?
 
When a user saves a query, what does that query or data structure look like?
 
PTNL said:
When a user saves a query, what does that query or data structure look like?
Click to expand...

that's what I'm asking for -- guidance on how to do it. I've not coded that up but when I thought about it, it seemed like I need to do this "the right way" to make it scalable.

the queries themselves get created in real-time on-the-fly based on the widgets that are present and their orientation on the page.
 
yes, it's like Report Builder in terms of ease-of-use but the GUI is more similar to iGoogle that Report Builder

I guess where I'm stuck mentally (and this will probably all seem obvious once I break through the mental wall) is how to store the entire series of search terms since each search term is independent.

what's a good way to put that back into the cookie/xml/sql-table in a way that I can deterministically re-create the layout the next time the user comes back _and_ so that they can share it with other users?
 
Code: 
[U][SIZE=3]searchTerms
[/SIZE][/U][SIZE=3][SIZE=2]id INT
term VARCHAR

[SIZE=3][U]savedQueries
[/U][SIZE=2]id INT
userId INT
date DATETIME

[SIZE=3][U]queryOrder
[/U][SIZE=2]id INT
queryID INT
termID INT
position INT

That's what I came up with off the top of my head. Would allow you to save the queries and easily rebuild them.
[/SIZE][/SIZE][/SIZE][/SIZE][/SIZE][/SIZE]
 
Where are you storing the user's search(database? cookie? wax blocks? :p)?
How would you use a stored search to rebuild the screen state?
How are you pulling search preferences from the screen to build the query?
 
Pwyl_The_Destroyer said:
Where are you storing the user's search(database? cookie? wax blocks? :p)?
How would you use a stored search to rebuild the screen state?
How are you pulling search preferences from the screen to build the query?
Click to expand...

that's the entire point of this thread. I don't know. I'm looking for suggestions and best practices.
 
First if you're doing something with loosely structured data and need to quickly search it and add to it without a great deal of drama STAY AWAY FROM SQL. SQL isn't the answer for everything. It does great with highly structured data and predictable deterministic queries but other stuff not so much. Look at CouchDB, memcache and Hadoop. These are a lot more flexible and extremely (read Facebook-size) scalable. Google has some great tutorials up on the changes you'd need to do and the ways to thing about your data. I'm a fan of these technologies, especially CouchDB, because it doesn't force me into a rigid format for my search data. It does equally well with image/CAD drawing metadata search, to XML (it's 2nd strongest point), hiding the complexity of it's replication pretty well (it's best point).
 
shadowkill said:
First if you're doing something with loosely structured data and need to quickly search it and add to it without a great deal of drama STAY AWAY FROM SQL. SQL isn't the answer for everything. It does great with highly structured data and predictable deterministic queries but other stuff not so much. Look at CouchDB, memcache and Hadoop. These are a lot more flexible and extremely (read Facebook-size) scalable. Google has some great tutorials up on the changes you'd need to do and the ways to thing about your data. I'm a fan of these technologies, especially CouchDB, because it doesn't force me into a rigid format for my search data. It does equally well with image/CAD drawing metadata search, to XML (it's 2nd strongest point), hiding the complexity of it's replication pretty well (it's best point).
Click to expand...
Overall this is disjointed rationalization, with an ambiguous use of the term "SQL", and several points are based on pure supposition. The OP's interesting in object design, and a database* is an acceptable way to store data, structured however you choose, but preferably in a useful and normalized design. There are plenty of other queryable container formats; b-tree is but one possible solution.

Thus far, I feel some research on data modeling (along with understanding data types), object modeling, and other related concepts are the most beneficial for the OP. Implementation decisions, caching, how and why to split workloads, etc. are certainly out of scope right now.


* Assuming you are referring to a database vendor product.
 
Last edited:
You must log in or register to reply here.
Back
Top