Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > Web программирование > SQL, базы данных
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 12.03.2014, 21:02   #1
Illusiony
Форумчанин
 
Регистрация: 17.02.2014
Сообщений: 881
По умолчанию Построение таблиц и логики для специфических задач

Допустим имеется таблица Mysql "объекты".
В ней постоянно нужно обновлять данные.
Необходимо чтобы каждый объект был уникальным ( на каждый объект по 1 записи)
В тоже время таблица будет постоянно разрастаться до бесконечности, что тоже плохо.
Можно ли сделать так?:
- автоинкремент оставить
- при удалении объекта в определенном поле записывать допустим "del" и в дополнительную таблицу, например "удаленные оъекты" записывать id автоинкремента данного удаляемого объекта.
- при записи нового объекта сначало производим анализ дополнительной таблицы "удаленные оъекты" ,если есть хоть 1 запись, то берем ее ( это и есть id автоинкремента в основной таблице "объекты") по этому id находим запись и перезаписываем данные.

Таким образом размер таблицы будет небольшой определяемой лишь общим количеством объектов + разницей между удаленными и новыми объектами. Также будет соблюдаться уникальность.

Это нормальный способ или я изобретаю велосипед и есть чтото по проще?

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

Как выйти из положения?
Первое что приходит в голову + еще одна дополнительная таблица "удаленных объектов №2" куда будут записываться все параметры удаленных объектов. И надо как то организовать понимание разницы в id основной таблицы "объектов" и id в "удаленных объектов №2".

Поделитесь мыслями опытные программисты.

P.S. Я же всего лишь энтузиаст самоучка
Illusiony вне форума Ответить с цитированием
Старый 12.03.2014, 21:35   #2
Аватар
Старожил
 
Аватар для Аватар
 
Регистрация: 17.11.2010
Сообщений: 19,042
По умолчанию

Что-то вроде этого использовал с dbf-файлами еще в досовском FoxPro в новеловской сети. Там в этом был смысл в силу особенностей удаления записей в таблицах. В современных СУБД совершенно бессмысленное занятие. Имхо. Да еще вред - в силу снижения эффективности. По поводу инкремента - знаковый интежер формат больше пары миллиардов значений, или 4 беззнаковый. Есть конечно базы, для которых этого маловато будет, но сомневаюсь, что это ваш случай
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию

Последний раз редактировалось Аватар; 12.03.2014 в 21:41.
Аватар вне форума Ответить с цитированием
Старый 12.03.2014, 22:33   #3
Illusiony
Форумчанин
 
Регистрация: 17.02.2014
Сообщений: 881
По умолчанию

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

Попутно еще 1 вопросик больше по логике чем по SQL.
Вот эту мою таблица основная "объектов" строится на основе других таблиц. В общем если на пальцах то, допустим имеется какой то объект и несколько направлений его улучшения ( каждое улучшение независимо увеличивает характеристики объекта)
Так вот допустим имеется 10 таких объетов и 3 направления улучшения, притом каждое улучшение имеет , допустим 5 левелов.
Если проследить все возможное комбинации то их будет очень много и каждую нужно отдельно описывать. Вот я и сделал таблицу "объектов" чтобы рассчитывать необходимые характеристики из этих 3х таблиц чтобы уменьшить объем работ. Но как известно у монеты 2 стороны, так вот этот метод повлек усложнение логирования за счет того, что на так сказать слепленный объект в таблице "объекты" ссылку дать нельзя, так как строка с уникальным id может быть перезаписана новыми данными.
Не знаю как найти выход из положения.
Палка о 2х концах. Сперва вроде все упрощается и уменьшается , а в конце ведет в тупик.

Последний раз редактировалось Illusiony; 12.03.2014 в 22:45.
Illusiony вне форума Ответить с цитированием
Старый 12.03.2014, 22:41   #4
Аватар
Старожил
 
Аватар для Аватар
 
Регистрация: 17.11.2010
Сообщений: 19,042
По умолчанию

Ну а зачем вместо удаления записи какой-то del писать в поле? Не вижу смысла
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию
Аватар вне форума Ответить с цитированием
Старый 12.03.2014, 23:24   #5
Illusiony
Форумчанин
 
Регистрация: 17.02.2014
Сообщений: 881
По умолчанию

Потому что автоинкремент от этого не уменьшится и следующий id номер будет на 1 больше предыдущего в не зависимости удалили ли строку или нет. В этом случае количество строк таблицы может быть малым, но индекс (id) в конце концов дорастет до миллионов.
Illusiony вне форума Ответить с цитированием
Старый 12.03.2014, 23:29   #6
Аватар
Старожил
 
Аватар для Аватар
 
Регистрация: 17.11.2010
Сообщений: 19,042
По умолчанию

Цитата:
но индекс (id) в конце концов дорастет до миллионов
Не индекс, а значение идентификатора. Да хоть до миллиарда. Ну и что? Где-то кому-то мешает, что id=999999999? Все равно те же 4 байта, что и id=1. Вспомните о миллиардах из поста #2. Вот у меня сейчас лет 5 эксплуатируемая задача, в базе порядка сотни таблиц, до миллиона ни одна id еще не дошла (наверно), до миллиарда никогда не дойдет. Ну разве что сотню лет будет эксплуатироваться. Но такого не бывает, еще несколько лет, ну максимум с большущей натяжкой 10 - и её выбросят, новое ПО и база или что там будет на тот момент. Вот сверхбазы с миллионами записей в сутки - это да, но там другой подход к таким вещам и мне и вам это не грозит
Если бы архитекторы строили здания так, как программисты пишут программы, то первый залетевший дятел разрушил бы цивилизацию

Последний раз редактировалось Аватар; 12.03.2014 в 23:40.
Аватар вне форума Ответить с цитированием
Старый 13.03.2014, 00:07   #7
Illusiony
Форумчанин
 
Регистрация: 17.02.2014
Сообщений: 881
По умолчанию

Надо подумать еще.
А так я хочу попробовать онлайн многопользовательскую игрушку сделать. Скорость обновления записей в сутки думаю может дойти до тысяч или даже десятков тысяч.
Тем не менее это не решит мой вопрос о логировании. Записей все равно не будет и ссылка соответсвенно приведет на не существующие данные
Как то нужно решать эту проблему. Но так не хочется вручную прописывать все возможные комбинации улучшений, придется уменьшать вариации= уменьшать юзабилити
Illusiony вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Построение таблиц функций. Mary1108 Помощь студентам 2 15.12.2013 22:22
алгебра логики LiR1Ka Помощь студентам 3 07.06.2011 22:37
Решение задач с использованием Электронных таблиц. vinil Помощь студентам 1 18.02.2011 21:29
Решение задач с использованием Электронных таблиц. vinil Помощь студентам 0 18.02.2011 21:19
TSysCharSet и функция удаления специфических символов из строки. DrAndriy Общие вопросы Delphi 0 07.09.2010 14:06