Home/ Questions/Q 3663770
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-19T01:34:06+00:00

Ok, I have a database with with a table for storing classified posts, each

  • 0

Ok, I have a database with with a table for storing classified posts, each post belongs to a different city. For the purpose of this example we will call this table posts. This table has columns:

id        (INT, +AI),
cityid    (TEXT),
postcat   (TEXT), 
user      (TEXT), 
datatime  (DATETIME), 
title     (TEXT), 
desc      (TEXT), 
location  (TEXT)

an example of that data would be:

'12039',
'fayetteville-nc',
'user@gmail.com',
'December 28th, 2010 - 11:55 PM',
'post title',
'post description',
'spring lake'

id is auto incremented, cityid is in text format (this is where I think i will be losing performance once the database is large)…

Originally I planned on having a different table for each city and now since a user has to have the option of searching and posting through multiple cities, I think I need them all in one table. Everything was perfect when I had one city per table, where I could:

SELECT       *
FROM         `posts`
WHERE        MATCH (`title`, `desc`, `location`)
    AGAINST ('searchtext' IN BOOLEAN MODE)
  AND        `postcat` LIKE 'searchcatagory'

But then I ran into problems when trying to search multiple cities at one time, or listing all of a users posts for them to delete or edit.

So looks like I have to have one table with all the posts, and also match another FULLTEXT field: cityid. I am guessing I need full-text because if a user chooses an entire state, and my cityid is “fayetteville-nc” I would need to match cityid against “-nc” this is only an assumption and I would love another way. This database could easily reach over a million rows within 6 months, and a fulltext search against 4 columns is probably going to be slow.

My question is, is there a better way to do this more efficiently? The database has nothing in it now, except for some test posts made by me. So I can completely redesign the table structure if necessary. I am open to any and all suggestions, even if it is just a more efficient way to perform my query.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Yes, one table for all posts sounds sensible. It would also be normal design for the posts table to have a city_id, referring to the id in a city table. Each city would also have a state_id, referring to the id in a state table, and similarly each state would have a country_id referring to the id in a country table. So you could write:

    SELECT $columns
FROM posts JOIN city ON city.id = posts.city_id
WHERE city.tag = 'fayetteville-nc'

    Once you’ve brought the cities into a separate table, it might make more sense for you to do the city-to-city_id resolving up front. This fairly naturally happens if you have a city chose from a dropdown, for instance. But if you’re entering free text into a search field, you may want to do it differently.

    You can also search for all posts in a given state (or set of states) as:

    SELECT $columns
FROM posts
     JOIN city ON city.id = posts.city_id
     JOIN state ON state.id = city.state_id
WHERE state.tag = 'NC'

    If you’re going to go more fancy or international, you may need a more flexible way of arranging locations into a hierarchy (e.g. you may want city districts, counties, multinational regions, intranational regions (Midwest, East Coast etc)) but stay easy for now 🙂

    • 0