From Chengen:------------------------
JT: Can't you give me the list of what places you want to put into the DB?
From JT:--------------------------------
The Places in WHERE, quite a few are related with food and drink, like:
Restaurants, Bars&Clubs, After-Work Bar, Cheap Eats, Romantic Dining, Bakery,
Food(it has coffee and Gourmet stores). Others are: Grocery, Shopping, Hotel,
Travel, Spa&Beauty, Pool Table(*Billiard), Nightlife, Lounge.
Since people who play smartphone are mostly young to middle age people, so they
are targeting on these people.
Yelp has some others that are different: Drugstores, Bank, Gas Stations.
The list is about above. Please do your best and grab as many as you can.
Thanks.
From JT:----------------------------
Please also add Hospital too. Thanks.
From JT:-----------------------------
I don't know if it's better idea to put all places in one table, from
performance standpoint.
In my previous thought, we separate restaurant from other places since we may
start to release products with maybe restaurants only first. Restaurant_ID may
be set different than Business_ID.
Could you do this: Create another table, lets call it "Places" for now, copy
all existing restaurants to this table. Then put all other places to this table
also. In this case, we may just use Business_ID at single ID, and keep our
existing elgg_restaurant_info untouched (existing code is using this table, so
it's not wise to change table now).
Thanks!
From John:-------------------------------------------
I didn't look at how the tables are designed now and how the code is inserting
the data.
Duplicating the data could be a potential problem as well since now you have to
keep them in sync.
The other approach to separate the tables and avoid the conflict ID at the same
time is to introduce a global ID table. This table can have only the ID, and
category. When you insert new business anywhere, first insert to this table and
generate a global ID, then you can use this ID to insert to other tables. Of
course this could be tricky if the ID in other tables already has constraint to
be sequential and has to increase by 1 only.
In the long run, since the categories do overlap, and we should probably avoid
putting all places in one giant table, I think it will be beneficial to have
global ID managed separately.
If we have to change code to have a better structure for scalability, it's
better to do it now instead of later. The more we code into it, the harder it
will be to change the schema.
From Chengen------------------------------------------------
Yes. This is a good choice. I will do it.
From JT:------------------------------------------------
whatever we'll do, we'd better keep elgg_restaurant_info table unchanged, for
now. Since all existing code is building upon it. Once we have done designing
on all tables, we can switch at that time.
There are many ways to seperate businesses. John's way is a good way, whenever
we put a new business category, we generate a category ID for that business
(can be sequential). Then we use this category ID to generate a global business
ID in other individual business tables, global ID can be a string instead of
number. For example, if we use "1" as restaurant category ID, then a global
business ID for restaurants could be: "1-" + sequential ID for restaurants.
this global ID can be inserted after initial data has been store, one SQL query
will do it all. I remember in my last startup company, i designed the db at the
same way. sequential ID is separate colume than business_ID.
Original issue reported on code.google.com by jt.xion...@gmail.com on 10 Aug 2010 at 10:00
Original issue reported on code.google.com by
jt.xion...@gmail.comon 10 Aug 2010 at 10:00