MySQL и мелкие вопросы<< 1  ... 46 47 48 49 50  ... 75 >>    18.01.2014 / 01:43 |  |  aNNiMON    Супервизор 
   Сейчас: Offline 
 Имя: Витёк Регистрация: 11.01.2010
   | Dinisimys (18.01.2014/01:40)aNNiMON, да, и в чем проблема учет пояса?Юзерам из Японии придётся смириться с тем, что добавленные после 13:00 данные о тренировке занесутся в другой день. (у них часовой пояс GMT+9).
  __________________
   let live  |  
   18.01.2014 / 01:44 |  |  aNNiMON    Супервизор 
   Сейчас: Offline 
 Имя: Витёк Регистрация: 11.01.2010
   | Ладно, нафлудили мы с тобой здоровски, пойду спать, завтра утром со свежей головой посмотрю, как можно сделать лучше.
  __________________
   let live  |  
   18.01.2014 / 01:44 |  |  Freddy    Пользователь  
   Сейчас: Offline 
 Имя: Игорь Откуда: Воронеж Регистрация: 30.01.2010
   | aNNiMON,  CREATE TABLE stat(  
    id             INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,  
    user_id     INTEGER NOT NULL,  
    exer_id     INTEGER NOT NULL,  
    stat_date  DATETIME  
);  
   
CREATE TABLE stat_value(  
    id                  INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,  
    stat_id          INTEGER NOT NULL,  
    total              INTEGER,  
    weight           INTEGER,  
    FOREIGN KEY (stat_id) REFERENCES stat(id) ON DELETE CASCADE  
);  
  |  
   18.01.2014 / 01:46 |  |  Dinisimys    Пользователь  
   Сейчас: Offline 
 Имя: Денис Регистрация: 30.07.2012
   | aNNiMON, а , понял твой вопрос. Тебе тогда просто надо проверять при синхронизации, если дата одна и та же, то суммировать, и удалять тот, который раньше был.
   |  
   18.01.2014 / 01:48 |  |  aNNiMON    Супервизор 
   Сейчас: Offline 
 Имя: Витёк Регистрация: 11.01.2010
   | Freddy, да, я думал так, но мне потом сложно выборку делать будет. К тому же, получается, что id и stat_id будут всегда равны, так как на одну запись в stat приходится одна запись в stat_value.
  __________________
   let live  Изменено aNNiMON (18.01 / 01:51) (всего 2 раза) |  
   18.01.2014 / 01:51 |  |  aNNiMON    Супервизор 
   Сейчас: Offline 
 Имя: Витёк Регистрация: 11.01.2010
   | Dinisimys (18.01.2014/01:46)aNNiMON, а , понял твой вопрос. Тебе тогда просто надо проверять при синхронизации, если дата одна и та же, то суммировать, и удалять тот, который раньше был.И тогда при второй синхронизации эти данные сложатся сами с собой    Я это уже проходил, за две минуты значения выросли из 10 до 10000000    __________________
   let live  Изменено aNNiMON (18.01 / 01:51) (всего 1 раз) |  
   18.01.2014 / 01:59 |  |  Freddy    Пользователь  
   Сейчас: Offline 
 Имя: Игорь Откуда: Воронеж Регистрация: 30.01.2010
   | aNNiMON,  нет, stat.id и stat_value.stat_id связаны отношением "один ко многим", ты сможешь добавлять в stat_value сколько угодно записей с одним stat_id. Сложностей с выборкой не вижу пока ;-/
   |  
   18.01.2014 / 02:16 |  |  aNNiMON    Супервизор 
   Сейчас: Offline 
 Имя: Витёк Регистрация: 11.01.2010
   | Freddy,  Так то оно так, но у меня для одной записи в stat только одну запись в stat_value надо хранить. Вот и получится, что три поля будут одинаковы. Добавляем в stat: id: 1, user: 3, exer: 9, date: 2014-01-18 В stat_value: id: 1, stat_id: 1, total: 40 И так каждый раз три поля будут увеличиваться равным образом.
  __________________
   let live  |  
   18.01.2014 / 02:34 |  |  Freddy    Пользователь  
   Сейчас: Offline 
 Имя: Игорь Откуда: Воронеж Регистрация: 30.01.2010
   | aNNiMON, а-а, я сначала не так понял вопрос. Для связи "один к одному" с каскадным удалением надо так: CREATE TABLE stat(  
        id             INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,  
        user_id     INTEGER NOT NULL,  
        exer_id     INTEGER NOT NULL,  
        stat_date  DATETIME  
    );  
   
CREATE TABLE stat_value(  
        id                  INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,  
        total              INTEGER,  
        weight           INTEGER,  
        FOREIGN KEY (id) REFERENCES stat(id) ON DELETE CASCADE  
);  
  |  
   18.01.2014 / 13:50 |  |  Dinisimys    Пользователь  
   Сейчас: Offline 
 Имя: Денис Регистрация: 30.07.2012
   | aNNiMON (18.01.2014/01:51)И тогда при второй синхронизации эти данные сложатся сами с собой   Я это уже проходил, за две минуты значения выросли из 10 до 10000000  Теперь понял. Я просто ничего не знаю в работе андроид-приложений с интернетом. Ну тогда тебе надо записывать в базу данных время, которое было последним в андроиде, а потом сравнивать эти времена при следующий синхронизации, если они одинаковы(вплоть до секунды), тогда не слаживать, а если нет - слаживать. Получается, та: у нас эсть запись, которая добавленна утром в 8:00, 30 отжиманий. Дальше мы через андроид добавили 40отжиманий в 19:00. При синхронизации проверка, если в один и тот же день добавление произошло, тогда суммируем, и в бд записываем время 19:00. Тогда, при следующей синхронизации в андроиде у нас записано 40отжиманий в 19:00, мы же проверяем время. если оно совпадает, тогда ничего не делаем, а если уже произошли какие-то изменения, тогда суммируем. Это такое решение, если я все правильно понял.   |  
 << 1  ... 46 47 48 49 50  ... 75 >>     Всего сообщений: 750  Фильтровать сообщения
  Поиск по теме
  Файлы топика (22) 
                 |