I'm developing a website (using asp.net-mvc) with a SqlServer 2005 database.
I have numerous database tables which drive content pages for the site e.g. I have a table called Activity:
Activity
-----------
ID
Name
So for each activity record, there would be a corresponding 'Activity' page. The same applies for other tables e.g. Location and Person etc.
For the purposes of SEO I want to allow storing of additional info for pages such as html meta title/descritpion/keyword info, and perhaps even page content.
I'm considering two main options to do this:
1) Modify Activity, Location and Person tables to include the relevant fields to hold this additional info
or
2) Create a PageInfo table to hold all this info in the same place, then simply add a PageInfoID field to the above mentioned tables
What are the pros and cons of these approaches and are there any better ways of doing this?
(One con I can think of for option 2 is that you can't really enforce the 1:1 relationship, so you could, theoretically, have a PageInfo record used by an Activity record and a Person record.
If i may suggest.. you may be going about this SEO thing the wrong way.
Rather than trying to pack each page with additional meta-data per 'Activity' object to get better search results from the page, i think you should concentrate on simply putting the 'Activity' data into the page with clean, semantic, valid XHTML and CSS. This way, search engines will worry about finding out which part of each page is of the most importance and index/rank that accordingly.
Also, trying to add these 'page meta' objects to the domain model of your system will create all sorts of conceptual (and indeed practical) problems for your design and it will certainly be confusing to users who will struggle to understand what the importance of the difference between say an Activity Title verses a Page Title is. Let the bots figure our keywords from your content, dont try to do it yourself - this type of over-optimisation will actually end up resulting in worse page rankings than better ones.
Related
We have a document base that needs the metadata to be structured in order to facilitate search, but due to the nature of the information, it will be impossible to use constraints. Tagging seems like an interesting option: it keeps the metadata structured, but allows users to create new values on the fly.
The problem with this solution is that each property needs to have a specific pool of tags. Imagine a document with two properties:
Entity
Process
In theory, we could put this information into metadata fields with constraints (database backed even), but the users want to be able to create values on the fly. Tags seem interesting, but we don't want to mix tags from the Entity list with tags from the Process list. Each tag should have its own "pool".
Has anyone done something like this in Alfresco? It seems like we'd have to tear apart the tagging system and basically rewrite it, but maybe it's easier than that.
If your only issue with tag is related to on the fly creation then you should look into "Categories". In Categories only admin user can create required Category structure.Then normal user will be able to use them to categories docs.
I your case I guess you require something like this
Entity
Entity1
Entity2
Entity3
....
Process
Process1
Process2
Process3
.....
If yes, you should b able to use categories.
Consider a set of data called Library, which contains a set of Books and each book contains a set of Pages.
Let's say you are using Riak to store this data, and you need to be access the data in two possible ways:
- Query for a particular page (with a unique id)
- Query for all pages in a particular book (with a unique name)
Additionally, you need to be able to easily update and delete pages of a particular Book.
What would be the best way to accomplish this in Riak?
Obviously Riak Search will do the trick, but maybe is inefficient for what I am trying to do. I am wondering if it makes sense to set up buckets where each bucket can be a Book (which would make for potentially millions of "Book" buckets). Maybe that is a bad idea...
Can this be accomplished with secondary indexes?
I am trying to keep this simple...
I am new to Riak and I am trying to find the best way to accomplish something that is probably relatively simple. I would appreciate any help from the Stack Overflow community. Thanks!
A common way to model master-detail relationships in Riak is to have the master record contain a list of detail record IDs, possibly together with some information about the detail record that may be useful when deciding which detail records to retrieve.
In your example, you could have two buckets called 'books' and 'pages'. The master record in the 'books' bucket will contain metadata and information about the book as a whole together with a list of pages that are included in the book. Each page would contain the ID of the 'pages' record holding the page data as well as the corresponding page number. If you e.g. wanted to be able to query by chapter, you could also add information about which chapters a certain page belongs to.
The 'pages' bucket would contain the text of the page and possibly links to images and other media data that are included on that page. This data could be stored in yet another bucket.
In order to get a specific page or a range of pages, one would first retrieve the master record from the 'books' bucket and then based on the contents of the record the appropriate pages. Even though this requires several GET operations, they are all direct lookups based on keys, which is the most efficient and scalable way to retrieve data from Riak, so it is will perform and scale well.
This approach also makes it simple to change the order of pages and/or chapters as only the master record needs to be updated. Adding, deleting or modifying pages would however require both the master record as well as one or more detail records to be updated, added or deleted.
You can most certainly also solve this problem by adding secondary indexes to the objects and query based on this. Secondary index queries in Riak does however have to include processing on a covering set (generally ring size / n_val) of partitions in order to fulfil the request, and therefore puts a bit more load on the system and generally results in higher latencies than retrieving a single object containing keys through a direct key lookup (which only needs to involve the partitions where the object is actually stored).
Although maintaining a separate object containing indexes adds a bit of extra work when inserting or deleting pages/entries, this approach will generally result in more efficient reads, as only direct key lookups are required. If your application is heavy on reads, it probably makes sense to use this approach, while secondary indexes could be more efficient for a write heavy application as inserts and modifications are made cheaper at the expense of more expensive reads. You can however always add secondary indexes just in case in order to keep your options open.
In cases like this I would usually recommend performing some benchmarks to test the solutions and chech which solution that best matches you particular performance and scaling requirements.
The most efficient way will be to store hole book as an one object, and duplicate it's pages as another separate objects.
Pros:
you will be able to select any object by its key(the most cheapest op
in riak is kv query)
any query will be predicted by latency
this is natural way of storing for riak
Cons:
If you need to update any page you must update whole book, and then page. As riak doesn't have atomic ops, you must to think how to recover any failure situation (like this: book was updated, but page was not).
Riak is about availability predictable latency, so if you will use something like 2i to collect results, it will make unpredictable time query, which will grow with page numbers
Lets say I have three webpages - one for big cars, one for middle sized cars, and one for little cars.
Each page is almost identical and consists of a form where you can select to filter a list of cars by colour etc and a submit button. On the client side the only difference is the title.
On the server side the only difference is in the where clause, for example:
... where car_type = "big" and color = %s, Response.Form['color']
But how can I save myself creating three different asp scripts for each page? How do I pass around which car_type I have?
I was thinking maybe by using a query string, but the query string data will be lost when the user presses the submit button.
Thanks,
Barry
You've found one solution yourself. Might not be the best one, though. When programming you always want to minimize redundancy, to avoid code duplication, because it'll invariably become a maintenance hassle, if not nightmare. So you really want to avoid creating three identical pages with just a tiny parameter difference.
Why don't you simply create one single page containing a select menu for the type of vehicle to search for? You could attach an onselect handler using Javascript to that menu which would reload the page if that's necessary. (And it might not even be.) In some menu, you could have links pointing to this page (search.asp or whatever) containing the vehicle type like this:
search.asp?type=L
search.asp?type=M
search.asp?type=S
Just an idea. Toy around with the code and that way you'll learn a lot. ASP is an old technology but I think a very good one for learning web applications. Do read the docs to learn about the facilities it affords you to avoid duplicating code. Here's a collection of things I found useful.
One way to do this is to use the query string the first time the page is accessed and then a hidden field to pass on the car type on filtering.
I have about 20 different tables that each have a different parent / child relationship built into them. I've recently been asked to create a breadcrumb and Site Map for our website based off of all of these tables.
One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId and whenever I need to pull the parent child relationship I would just join the parent_child_relationships table to whatever table I was pulling from specifically.
Does this make sense?
Anyway, the problem with this idea is that i don't like it. haha.
Does anyone else have any other ideas of how this could be done? Or what the correct way of building a breadcrumb and sitemap based off of a site comprised of 20 tables or so?
If it helps, my site is comprised of asp.net, ColdFusion and uses a MSSQL database.
Thanks!
Do not let the implementation of the UI effect the design of your model and especially not your DB. Prototype the front end, involve your customer(s), give them a voice. Build your breadcrumbs and site map without it initially tied into your actual DB. Once your customer says "thats what we want, just like that", then freeze the prototype, then work on the actual implementation - how will your app request the data, what type of dataobject will you use AND THEN build your db,
"One idea I had, was to remove the parent / child relationship from each of these tables and create basically one table that holds the id and parentId"
This is not a very scalable solution, do not *reverse normalize your db. Follow standard relation database modeling/normalization techniques. Lots of small cohensive tables with lots of association tables.
When and why would it be a good choice to keep the view of two different sets of information on the same page, and just change what's visible depending on different parameters?
For example, an application I'm working on has three levels of users: Admin, Director and Project Manager. We have a Managers.aspx page which follows this flow of control:
If user is admin, load gridview list of directors with several simple CRUD-like properties. This includes a link for each director that, when clicked, will load a new gridview with several properties of all of the Project Managers belonging to the selected director.
If user is director, load straight to the list of Project Managers that belong to this director, in the exact fashion as described in the second half of the "if user is admin" clause".
This is all done on one Managers.aspx page. Why? What advantage does this hold? When else might this type of situation arise? Personally, this seems like a job for two separate pages. One listing the directors, and another listing the Project Managers.
Thanks in advance :)
As you pointed out, most of the logic for those two requirements is the same: get a list of users, present them in a gridview, apply simple CRUD functions. Doing this as two separate pages would require all that code to be repeated twice, and then kept in sync.
The only real difference between the two screens is which users it shws by default... That's one if-statement of difference in a pageful of code..
As stobor indicates - when you don't want to write the same code twice.
Using the one page solution, the decision about which view to display is made on that one page. If you separate the different views out to different pages, you have to make this decision every time you need to display this data. So rather than one single if/else in Managers.aspx to determine the view, you have multiple if/else statements on multiple pages which are intended to decide whether to load AdministratorManagers.aspx or DirectorManagers.aspx.
Provided your application is robust enough, and you're not doing something stupid like determining which page to show based on a querystring value, there is no real problem using one single page to display different views. In fact, many websites do this. What you don't want to do is use seperate but identical controls for each view, because then you're just going to end up with messy code. It may make sense to create custom controls called 'AdminView' and 'DirectorView' to at least allow you to think of the two views as separate entities, but you'll have to decide for yourself whether this will be a headache-saver or a waste of time.