Структура базы для координатов

Ваша структура неправильная. Совсем.

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

С такой структурой возможна вероятность аномалий, проблем с производительностью и модернизацией функционала.

Для построения структуры базы данных необходимо обладать знаниями о нормальных формах базы данных, хотя бы о первых трех. Попробуем нормализовать вашу структуру. Нормальные формы базы данных и законы построения базы легко можно найти в поисковой системе.

Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).

Структура должна быть примерно следующая по вашей задаче:

1) Родители

• id (первичный ключ)
• фамилия
• имя
• отчество
• номер
• email (уникальный ключ)
• пароль
• дата регистрации

2) Дети

• id (первичный ключ)
• фамилия
• имя
• отчество
• телефон
• дата создания записи

3) Таблица для связи родителей с детьми

• id родителя (первичный составной ключ id_родителя_id_ребенка)
• id ребенка (первичный составной ключ id_родителя_id_ребенка)

4) Таблица координат

• id координаты (первичный ключ)
• id ребенка (составной индекс id_ребенка_дата)
• ширина
• долгота
• дата (составной индекс id_ребенка_дата) - Поле дата я добавил, потому что родители вероятно захотят знать, где их ребенок был в определенное время.

Будем считать, что вероятно, к данным координатам будут созданы отношения в других таблицах. Например, родитель захочет пометить подобную координату своего ребенка, как тревожную или оставить по ней комментарий, следовательно поле id должно быть. Если ситуация иная, то поле id не имеет смысла, как в таблице 3.

Пункт координаты ребенка в изначальной схеме не нужен, ведь они будут получаться через запрос.

Далее, будем считать что при обновлении координат каждые 30 секунд в день будет 2880 координат, а в месяц 86400 координат на одного пользователя или миллион записей в год.

Для классической базы данных, такое количество данных это пустяк, а место сейчас дешевое, так как данные будут сформированы и вероятно будут выбираться по временному интервалу из индекса, например за последний день - быстродействие будет высокое.

Хотя, данные в подобных системах долго не хранятся и можно ограничиться например 3 месяцами хранения подобной информации, а остальное удалять.

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

Касательно структуры БД:

Почему у тебя в пользователях есть родители и дети?

Я бы разбил таблицу на 3 сущности:

1. Родитель
2. Родитель-ребенок (1 ребенок принадлежит Маме и Папе)
3. Ребенок

Почему у тебя пользователи ссылаются на координаты?

Имхо: Если ты назвал таблицу, как пользователи, то она и должна хранить информацию только о пользователях. Я бы их не связывал их между собой.

Если выполнить оптимизации, которые я предложил выше, то, связав 4 таблицы ты получишь нужную информацию.

P.S Для проектирования БД лучше использовать Toad DataModeler или ERWin, для удобства.

Теперь по первому вопросу

На одного человека в день будет создана ровно 720 строчка в таблице координат.

Как я понимаю | id записи | id ребенка -это int=> 4 байта=> на 2 поля уходит 8 байт.

Остальные 2 поля, как я понимаю, DOUBLE=> 8 байт=> на 2 поля 16 байт.

Итого получаем, что без учета индексов на одну строчку будет расходоваться 24 байта.

24*720=17280 байт/16,875 килобайт

Теперь ты можешь это умножить на примерное кол-во детей и прикинуть возможности. По идее, если ты будешь вычищать мусор, то все должно быть хорошо.