![]() ![]() Most of the columns in this table are self-explanatory, except the following: The user_account table holds users’ preliminary details, which are captured during the registration process. The application inherits this information from the user_account table and binds the post with the location of the user who publishes it. The critical information about a post is its tagged location ( county_id and zip). Therefore, capturing users’ roles is not needed for this application. Of course, this also applies to advertisers they may use their account for more than one purpose. We cannot distinguish users by their roles here because a seller can become a buyer and vice versa. ![]() Users can be buyers, sellers, or advertisers. Therefore, searches must be address- and postal-code-driven and should display results in the user’s vicinity unless they explicitly request results for another location. A user in London will usually prefer to see search results in and around London. Data archival should be seamless, never degrading the application’s performance when the archival process is in progress. ![]() Older data is archived in a data warehouse and is made available only to business analysts or for reporting purposes. Usually such portals keep the previous 30 or 60 days of data for display to end users. The list of data fields keeps evolving, and no architect wants to change the data model every time a new requirement comes in. Once smartphones hit the market, this information became largely irrelevant. For example, a few years ago, it was important to note which type of keypad a mobile phone had. Also, when the platform gains popularity, the database should be able to support the growth. The app must be able to support a wide range of products and services while allowing granular details in the posts. Most of the time, the fields will vary within the same category for instance, the application should not capture the same set of data fields for a bike as it does for a motorcycle. The data captured in selling a car is definitely different than that for renting a house. Besides huge data volumes, we must consider the many types of data we’ll store.I will explain its usage later in this article for now, let’s concentrate on the requirements of this data model. However, Oracle has included some beautiful features that allow developers to build an efficient and smart application while still keeping data in a relational format. Add to this the fact that posts are viewed many times and that Craigslist carries out innumerable search requests – many of which happen simultaneously – and you can see the kind of performance that we’d need!ĭesigning such a database is almost a nightmare, especially when using a relational database like Oracle. Craigslist, which operates in more than 270 cities in over 50 countries, gets 1.5 million new posts every day. When I think of developing a classified advertising platform, I immediately think of the huge volume of data involved. What Does It Take to Run an Online Classified Ad Platform? In this article, we’ll see how to design an optimized, performance-friendly database model for such a platform. Online classified ads (such as Craigslist) offer a place to buy or sell new or used products, advertise services, and connect with various people. Ever use Craigslist or some other online classified ad website to sell or buy something? Did you wonder how it worked? In this article, we talk about how an online classifieds data model can be designed using a relational database. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |