Логично делать базу, в которой для каждого форума - своя таблица, ну на крайняк несколько таблиц. Каждое сообщение уникально само по себе. В базах данных принято давать каждой записи числовое поле соответствия, так называемый ключ. Это ключевое поле, которое потом очень сильно помогает в поиске и прочих типовых операциях БД. Важно понять, что в более менее сложных БД ключ - всегда есть поле с неповторяющимися значениями. Для каждой таблицы есть одно ключевое поле, хотя можно создать несколько других идентификационных полей.

Вот. Таблица, одно ключевое поле, значения в поле не должны повторятся. Теперь. Я решил сделать по-простому, взять в качестве ключевого поля номер сообщения, который есть последнее число в урле сообщения. Увы, я плохой проектатор :) Я не думал, что счётчики сообщений обнуляются. Я теперь не могу без дополнительных ухищрений заполнить микроконтроллерную базу. Мне нужно отказаться от ключёвости поля, т.е. отменить обязательную уникальность Id сообщения и ввести внутреннюю дополнительную идентификацию (что разумно), либо манипулировать диапазонами имеющихся номеров, чтобы номера были всегда уникальными и база была однообразна по структуре. Для других форумов такого геморра вроде не нужно, только для МК.

Вот я и думаю пока, взвешиваю как поступить. Вариант с диапазовами мне больше по душе почему-то, но для этого я должен знать где и когда происходили изменения счётчиков.

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

Ладно, расслабтесь, я че-нить всегда придумываю. Правильная организация структуры таблицы влияет на скорость операций по поиску записей в ней. Тем более, когда база переваливает за 4 Гига. При 500 000 сообщений каждая задержка имеет смысл мне кажется. Вот когда добью узнаю.