Вначале хотел в песочницу добавить — кармы не хватило, потом в персональный блог — тоже самое. Так что информационная безопасность показалась ближе всего.
Честные выборы нужны для возможности смены власти. Например, если вы сейчас за теперяшнюю власть, совсем не значит, что вы будете за неё через 5 лет… 10… или 17… А потом уже будет поздно. Т.к. все гайки закручены.
Кроме того если заранее известно, что после тебя обязательно будет другая власть, то и не захочешь, чтобы как только отойдёшь от власти оказался в тюрьме.
Например, если будет всё русскими буквами, то некоторые почтовые сервера не поймут какая кодировка. Для тела письма — в заголовках можно передать utf-8, а для сабжекта и to нужно добавить в само поле обозначение кодировки.
text
--old_id
--old_text (сам текст страницы)
--old_flags
Каждое изменение текста страницы создаёт новую ревизию и новую запись в таблице text.
Выборка страницы происходит так:
SELECT page_title,old_text,old_flags
FROM `page`,`revision`,`text`
WHERE page_is_redirect = '0'
AND page_namespace = '8'
AND (page_title NOT LIKE '%/%' )
AND (page_latest=rev_id)
AND (rev_text_id=old_id)
AND (page_len <= 10000)
А теперь, почему нам не подходит
1) один текст на страницу vs много ячеек в открытом документе.
2) у одного текста в медиавики — одна ревизия. У нас контент у ячеек может появляться в разных ревизиях.
3) Сама суть — у медиавики — кто-то зашел подправить текст. Сделал необходимые изменения, посмотрел на превью, сохранил. У нас — несколько пользователей как умолишённые одновременно заполняют ячейки, подбирают им цвет и т.п.
Теперь ещё по-поводу настоящих google docs — при просмотре истории ревизий — по умолчанию ревизии включают в себя не каждое изменение ячейки — а несколько недавних изменений, но если выбрать «show more detailed revisions» — тогда уже любое изменение можно посмотреть/откатить. Видно они место не экономят… Для нашей структуры, если необходимы абсолютно все изменения, а не только в рамках «жизни» ревизии — можно просто сделать так, чтобы ревизии всегда просрачивались экспаерелись.
Объясните, пожалуйста. Такая структура придумывалась не один день, и вариант с timestamp также рассматривался, но был отсеен как раз из-за непростой и небыстрой выборки данных, просмотра данных на какую-то дату и слишком быстрому разрастанию бд. Не говоря уже о том, что с ревизиями — при необходимости можно сделать несколько веток одного документа.
В итоге хотелось бы выяснить какая структура была бы идеальна для описанных в посте нужд.
Кроме того, что некоторым другим сущностям, кроме ячеек может понадобиться версионность, так и некоторым данным такая версионность будет не нужна — например, id, sheet_id, row_number, col_number, creator_id (т.е. вся таблица cells).
Не забывайте, что пример из поста сильно упрощён, чтобы объяснить алгоритм. В реальности — обязательно будут связи с другими таблицами. Всё тоже самое что и в обычной структуре любого проекта, только с версионностью некоторых данных.
Это звучит красиво, если не вдуматься как именно будут выбираться данные до заданного таймстемпа.
Как я полагаю, если делать через таймстемп (как из вашего примера) — нам понадобятся совершенно другие выборки. Т.е. последний вариант документа мы выбираем одним образом, предыдущие — совершенно по другому и как будет выглядеть запрос выбирающий значения ячеек на какую-то дату? Кроме того, как я полагаю, удаление записи будет выглядеть как затирание значений полей, для которых нужна эта версионность?
Восстановление данных также как и просмотр документа потребуют программирования отдельной логики. В описанном в посте примере просмотр данных на определённую ревизию и восстановление этих данных больше усилий не потребует.
Потом, у нас ещё есть не только значение ячейки, но и её цвет (а на реальном примере — будет намного больше параметров). Получается, что пока пользователь будет подбирать цвет ячейки каждый новый цвет будет создавать запись в бд.
А что нужно будет сделать для того чтобы посмотреть как выглядел документ раньше? В этом случае вся разница сведётся к тому, чтобы использовать timestamp вместо revision_id и быстрее точно не будет.
Кроме того если заранее известно, что после тебя обязательно будет другая власть, то и не захочешь, чтобы как только отойдёшь от власти оказался в тюрьме.
И от себя немного — почему просто так желательно не отправлять
Например, если будет всё русскими буквами, то некоторые почтовые сервера не поймут какая кодировка. Для тела письма — в заголовках можно передать utf-8, а для сабжекта и to нужно добавить в само поле обозначение кодировки.
Вобщем, у меня приблизительно так выглядит это:
Думаю, что phpmailer всё это учитывает.
revision
--rev_id
--rev_page
--rev_text_id
--rev_comment
…
--rev_parent_id
page
--page_id
--page_namespace
--page_title
…
--page_latest (где хранится айдишник последней ревизии)
text
--old_id
--old_text (сам текст страницы)
--old_flags
Каждое изменение текста страницы создаёт новую ревизию и новую запись в таблице text.
Выборка страницы происходит так:
А теперь, почему нам не подходит
1) один текст на страницу vs много ячеек в открытом документе.
2) у одного текста в медиавики — одна ревизия. У нас контент у ячеек может появляться в разных ревизиях.
3) Сама суть — у медиавики — кто-то зашел подправить текст. Сделал необходимые изменения, посмотрел на превью, сохранил. У нас — несколько пользователей
как умолишённыеодновременно заполняют ячейки, подбирают им цвет и т.п.Теперь ещё по-поводу настоящих google docs — при просмотре истории ревизий — по умолчанию ревизии включают в себя не каждое изменение ячейки — а несколько недавних изменений, но если выбрать «show more detailed revisions» — тогда уже любое изменение можно посмотреть/откатить. Видно они место не экономят… Для нашей структуры, если необходимы абсолютно все изменения, а не только в рамках «жизни» ревизии — можно просто сделать так, чтобы ревизии всегда
просрачивалисьэкспаерелись.Не говоря уже о том, что с ревизиями — при необходимости можно сделать несколько веток одного документа.В итоге хотелось бы выяснить какая структура была бы идеальна для описанных в посте нужд.
почитаюпосмотрю, спасибо за ссылку.Про количество ячеек не понял вопроса. Если это про «row_number» и «col_number» — то это номер рядка и номер колонки.
Не забывайте, что пример из поста сильно упрощён, чтобы объяснить алгоритм. В реальности — обязательно будут связи с другими таблицами. Всё тоже самое что и в обычной структуре любого проекта, только с версионностью некоторых данных.
Как я полагаю, если делать через таймстемп (как из вашего примера) — нам понадобятся совершенно другие выборки. Т.е. последний вариант документа мы выбираем одним образом, предыдущие — совершенно по другому и как будет выглядеть запрос выбирающий значения ячеек на какую-то дату? Кроме того, как я полагаю, удаление записи будет выглядеть как затирание значений полей, для которых нужна эта версионность?
Восстановление данных также как и просмотр документа потребуют программирования отдельной логики. В описанном в посте примере просмотр данных на определённую ревизию и восстановление этих данных больше усилий не потребует.
Потом, у нас ещё есть не только значение ячейки, но и её цвет (а на реальном примере — будет намного больше параметров). Получается, что пока пользователь будет подбирать цвет ячейки каждый новый цвет будет создавать запись в бд.