Привет всем!

Хочу услышать мнения по поводу того, как можно лучшим образом построить таблицы MqSql.

Вообщем мы имеем 2(две) таблицы, в эти таблицы заносяться объявления, в одну "купля" в другую "продажа".

Вопрос:
Как мне организовать работу PHP+MySql так, чтобы по "одному" идентификатору(например: 112) определять в какой таблицы выбирать данные, т.е. определить c одного ID(112) какой тип сделки купля или продажа.


Мой вариант решения пока такой:
Прибавлять цифры перед ID, к примеру 1-значит покупка, 2-значит продажа.
Заносить в таблицы при добавлении юзером, обычные ID (1,2,3...154,...987), а при выборке прибавлять цифру перед этим номером(11,12,13...1154,...1987).
пример:в таблице покупки 43, при выборке 143-значит покупка, в таблице продажи 52, при выборке 252-значит продажа.

Этот варик не плох, но имеется ряд нежелательных последствий, а именно:
1. после 99(199), появляется сразу тысяча - 100(1100), и т.д. - 9999(19999).
2. функции которые должны обрабатывать этот номер и соответственно после парсировки должна проходить выборка с определенной таблицы - это немного напряжно. 

Плюсы:
существуют две таблицы, а значит с ними легче работать, меньше нагрузка на базу при выборке и занесении объяв. 

Единственный правильный вариант -- хранить все объявления в одной таблице и каждому сопоставлять тип объявления из второй таблицы.

почему?

какие плюсы у твоего варика, и минусы у моего?

Добавлено через 2 минуты и 17 секунд
и еще... а если я например хочу чтобы юзер смог визуально отличать что за обьявы(покупка, продажа)

т.е. 245-значит продажа,  145-значит покупка

а по твоему варику получается, что все будут вида 145, 146, 147 ... или я ошибаюсь?

А пользователь должен сам метом дидукции дойти до того, что 245 это объявление о продаже?

Твой:
Минус один -- необоснованное хранение обнородных данных в разных таблицах. А если появятся объявления о аренде? )
Плюсов -- нет

Мой:
Да нет тут плюсов и минусов. Просто это правильная, логичная и удобная структура.

В том то и дело... поработав с данной структурой занесения и выборки инфы, я начинаю понимать, что прироста в скорости и выгоды от того что у тебя две таблицы особо не получишь. Поэтому и спрашиваю совета.

Есть ли у кого еще замечания, готов выслушать...   

Дело в том, что хранение в одной таблице однородных данных - это аксиома. Азбука построения БД. 
И как раз наоборот - это денормализацию данных надо обосновывать. Рассказывать, какие будут плюсы. Если они будут.

для этого надо в адресной строке писать не цифры, а слова. для продажи - sale, для покупки - buy. По словам гораздо проще определять, чем по цифрам.

На мой взгляд плюсы и минусы искать при рассмотрении вариантов не стоит. solenko предложил единственно правильный вариант. Нужно просто взять и использовать. Почему он правильный? Можно почитать про принципы проектирования реляционных баз данных и все станет понятно

Всем спасибо, впринципе все понятно и вопросов нет