Какая структура будет меньше загружать сервер?

[predefined]

Да, можно делать выборку сразу из нескольких связанных таблиц (JOIN), только в вашем случае это незачем. 2 запроса к БД займут миркосекунды, у вас выборки не сложные. Это не то, на чём надо экономить.

А держать всё в одной таблице - придётся дублировать в каждой строке все общие поля. Целостность данных при этом может пострадать.


PS: Современные движки делают до 200 MySQL-запросов для формирования одной страницы сайта.

[come-on]

можно делать выборку сразу из нескольких связанных таблиц (JOIN), только в вашем случае это незачем

это всегда зачем

[Illusiony]

predefined
"И можно ничего не мутить с "реализацией посылки сразу нескольких кликов, если их частота составляет быстрее 1 раза в секунду". В случае чего, очередь будет сделана операционной системой при приёме TCP/IP пакетов, и вторая - на MySQL если он не будет успевать за вашим скриптом."

Возможно я плохо объяснил. Под пакетами я имел ввиду обыкновенный post запрос в котором несколько кликов объединены в одну общую строку.
Думаю на счет реализации вашего предложения #27

Но опять хочу напомнить и спросить :

скорость посылки запросов от обоих программ врятли будет чаще 1 раза в секунду. Т.е. вероятность того что запросы от обоих программ придут в одно время чтобы случилась коллизия между отдельными запросами, наверняка, оооочень мала? Т.е. я как бы не уверен стоит ли вообще что то городить.

[predefined]

Illusiony, я под "пакетами" то же самое имел ввиду. Да, технически неграмотно выразился.

На счёт коллизий. TCP/IP - среда с негарантированной доставкой пакетов(тут уже "пакеты" именно те). По дороге пакеты могут дробится маршрутизаторами на более мелкие и потом собираться обратно маршрутизатором на выходе.
Любой такой мелкий пакетик может потеряться, тогда он будет отослан заново, и на это тратится время.

Поэтому в Интернете возможны коллизии, когда второй посланный пакет придёт вперёд первого.
Я бы не стал рисковать, и сделал обработку с учётом возможности одновременного прихода пакетов от обеих программ.
Потому, что отловить такие ошибки потом будет очень сложно. На одних провайдерах интернета всё будет работать, а на других - загадочно глючить.
Критично это или нет - решать вам. Может потеря пары пакетов с данными и не важна для работы ваших приложений.

[Illusiony]

predefined, А мне получается нужен формат времени в микросекундах? Ведь с дискретностью в 1 секунду возможно появление одинакового времени.
А вместо времени можно же присылать от программы просто счетчик с номером клика вместо timestamp . Сделать его например SMALLINT 65 тысяч вполне хватит до переполнения.

[Пепел Феникса]

Поэтому в Интернете возможны коллизии, когда второй посланный пакет придёт вперёд первого.

нет, TCP так же гарантирует и порядок в пределах одного соединения/потока.

ТС, я что-то смотрю, а вам точно вообще нужна БД?
может на очереди посмотреть?

[Illusiony]

Сообщение от Пепел Феникса

нет, TCP так же гарантирует и порядок в пределах одного соединения/потока.

ТС, я что-то смотрю, а вам точно вообще нужна БД?
может на очереди посмотреть?

Бд точно нужна, кроме того что я описываю, еще много чего будет и уже частично есть кое что.

[come-on]

можно и в базе очередь организовать весьма просто, но автор уперся в какието чистилки и еще не пойми во что

[predefined]

Сообщение от Illusiony

А вместо времени можно же присылать от программы просто счетчик с номером клика вместо timestamp . Сделать его например SMALLINT 65 тысяч вполне хватит до переполнения.

Можно, конечно. timestamp был сделан чтобы гарантированно не было переполнения в ячейке БД. Я же не знал объёмы ваших данных.
Как я понимаю, Приложение 2 просто должно знать порядок прихода данных,чтобы обрабатывать их в том же порядке, как они приходили.

Возможно, достаточно будет поля автоинкремент в БД, но тогда будет не "порядок отправки данных Приложением" а "порядок их поступления на сервер". Они могут не всегда совпадать, см поправку от Пепел Феникса выше.

Сообщение от Пепел Феникса

нет, TCP так же гарантирует и порядок в пределах одного соединения/потока.

Да. И если держать http-соединение постоянно открытым (keep-alive), очерёдность отправленных данных тоже должна соблюдаться.
Но автор планирует посылать данные отдельными http-запросами, там теоретически может быть и каша.

[predefined]

Сообщение от come-on

можно и в базе очередь организовать весьма просто, но автор уперся в какието чистилки и еще не пойми во что

Он ещё начинающий кодер, поэтому готовых "велосипедов" у него в арсенале нет.
Тем, не менее, он не поленился и в "поисках истины" накидал тест. Уважаю упорных и настойчивых.