Надеюсь вы не предлагаете основывать защиту системы на трудности подбора guid'а?
Я достаточно много использовал и guid'ы и числовые id. Реальное преимущество первого — именно при репликации и слиянии баз. Если этого не требуется — лучше использовать числа. С ними значительно быстрее и компактнее.
Классикой считается «Введение в системы баз данных» Дейта (http://www.williamspublishing.com/Books/…). Правда это глубокая теория. По конкретным вопросам и конкретным СУБД могу порекомендовать только поиск ответов в форумах. 500 тыщ. записей — это мелочи. По крайней мере беспокоится о времени выборки на таких объемах точно не стоит. Правильная индексация и порядок поиска будет log_2(500 тыщ) = 19.
А вообще для сильно больших таблиц существует разбиение на разделы (partition).
Кстати, строковый ИД хорошо делать в таблицах-справочниках. И в качестве значения использовать кодовое слово. В этом случае результаты запросов на основные таблицы получаются более наглядными.
Guid'ы — достаточно мощный инструмент, но использовать его стоит только по необходимости. Опять же в GET-запросах числовой ИД выглядит куда симпатичнее, чем guid.
Что юзер = конст, надо забыть сразу. Т.к. все-равно они будут добавляться, удалятся и редактироваться. Файлы в базе хранить не стоит — оставьте это промышленным системам, где необходима единая система контроля, репликации и т.п. Проше организовать хранилище на диске. С общим корнем, например /storage. Генерить уникальное имя файлу и путь к нему с учетом ИД владельца. Т.е. путь к файлу будет такой:
/storage/22/7622/qwertyuiop1234asd
где «7622» — ИД пользователя (конечно, если файлы имеют привязку в пользователю)
«22» — хэш-код, что б во-первых избежать огромного числа поддиректорий в stogare, а во-вторых в этом случае проще разносить storage на разные диски.
В целях экономии, фотографии при закачке резайзить до каких-то разумных размеров, т.к. большинство будет загружать фоты прямо с фотика.
С «микропостами» ничего хитрого придумывать не надо — обычная таблица. Для повышения производительности — кэширование на стороне сервера.
В свою бытность архитектором БД, разрабатывал достаточно серьезные базы. При разработке пользовался Power Designer'ом. Базовые принципы те же самые, что и для «маленьких» баз. Главное сложность — не утонуть в огромном количестве таблиц. На помощь приходит старая как мир техника — разделяй и властвуй. Т.е. разбить базу на составные части (модули), с большой «связаностью» внутри модуля и «слабыми» связями между модулями. Каждый модуль рисовать на отдельном листе, необходимые таблицы из других модулей показывать другим цветом и без перечисления полей (только квадратик с названием таблицы).
К примеру в какой-нибудь системе по учету товара можно выделить модули «юзер и права доступа», «товар», «баланс» и т.п. Соответственно при проектировании каждого модуля — внимание акцентируется уже на достаточно ограниченном наборе таблиц.
Вроде это тоже очевидно, но опять же практика показывает обратное — много раз видел схемы баз из сотни таблиц. Вся схема была на одном листе формата А1 и каждая таблица присутствовала в единственном экземпляре. Естественно такая таблица, как USER была связана практически с каждой второй таблицей и к ней вело порядка пятидесяти стрелочек, которые причудливо переплетались между собой. Единственная ценность такой схемы — нагнетать ужас на заказчика. Ибо с практической точки зрения работать с ней невозможно.
Еще хорошо придерживаться какой-то системы именования. К примеру с префиксами в именах таблиц:
ent_xxxxxx — обычная таблица с данными (от entity)
dct_xxxxxx — таблица-справочник (от dictionary)
ext_xxxxxx — таблица-расширение, из связи один-к-одному (от extention)
col_xxxxxx — связка многие-ко-многим (от collection)
Это опять же достаточно общие принципы. А единой статьи не эту тему, думаю не выйдет написать, т.к. слишком много частностей нужно учитывать. При разработке больших баз сталкиваешься с различными трудностями и ограничениями — решать их приходится в «индивидуальном порядке».
Я и сам не понимаю, как можно проектировать по другому. И полностью с вами согласен, что все сказанное интуитивно понятно и очевидно. Однако сейчас передо мной база на аксесе, в которой варварски нарушены все принципы. Все — в буквальном смысле. И мне с этой базой приходится работать. И по первым отзывам видно, что я не одинок.
Эта статья во-первых крик души. А во вторых — этакий ликбез. Я не сомневаюсь, в квалификации хабра-людей и уверен, что ничего нового для них здесь нет. Но ведь у всех бывают знакомые, которым иногда приходится заниматься вещами далекими от их повседневных занятий. В частности если этим знакомым, по каким-то причинам, нужно сделать базу — можно смело посылать их на эту статью.
Так создайте на хабре топик с просьбой о помощи — мы вас этими задачами завалим. Только определитесь что вам нужно — небольшой проектик или академические задачки.
Вот для начала:
- найти все расстановки восьми ферзей, которые не бьют друг друга.
- первые 100 знаков числа e (число Эйлера, основание натур. логарифма)
- первые 100 знаков числа Пи (3.14 которое)
- деление 100-значных чисел
чуть посложнее:
- «компилятор формул». По строке с правильной арифм. формулой посчитать значение. Пример строки «-3 + (3/(4+2))^2».
- «выпуклая оболочка» На плоскость в произвольном порядке падают точки. Нужно после падения каждой точки выдавать площадь и периметр «натянутого на них» многоугольника
Ложусь в 5, просыпаюсь где-то в 12 в час. Никакого дискомфорта не испытываю.
И поймите, я пропагандирую ночную работу. Просто при домашней работе в однокомнатной квартире и с маленьким ребенком это единственный выход, т.к. практически ни один из 30 пунктов реализовать на практике не получится.
Сейчас вынуждено работаю дома. Это единственное действенное ср-во. Всякие «границы для своих близких» и т.п. — теоретическая идеализация редко достижимая на практике.
Большой, в смысле достаточно продолжительный для того что бы отражать ход его выполнения прогресс-баром. А для «маленьких» нет большого смысла показывать прогресс их выполнения. Для них более чем достаточно обычной «крутилки», а то вообще никак их не афишировать.
Есть.
Отправили «большой» запрос (в смысле, долгий, который будет отражаться на прогресс-баре). И отдельными аякс-вызовами опрашивать сервер о состоянии этого «большого» запроса. Ну и соответственно отражать это состояние на прогресс-баре. Серверная часть, разумеется, должна давать адекватные ответы.
PS кстати — загрузка файла аякс-запросом не реализуется, но состояние загрузки отслеживается аяксом.
Само название «прогресс-бар» свидетельствует о назначении этого элемента. Он должен показывать «прогресс», т.е. в какой стадии находится выполнение некой задачи (загрузки файла, например). А представленная техника позволяет делать анимированные полоски, которые ничего не отражают. Т.к. скорость анимации прописана в гифе и управлять ей нет возможности.
Может для чего-нибудь это и сгодится, но точно не для «индикатора загрузки» и «прогресс-бара».
Я достаточно много использовал и guid'ы и числовые id. Реальное преимущество первого — именно при репликации и слиянии баз. Если этого не требуется — лучше использовать числа. С ними значительно быстрее и компактнее.
А вообще для сильно больших таблиц существует разбиение на разделы (partition).
Guid'ы — достаточно мощный инструмент, но использовать его стоит только по необходимости. Опять же в GET-запросах числовой ИД выглядит куда симпатичнее, чем guid.
Что юзер = конст, надо забыть сразу. Т.к. все-равно они будут добавляться, удалятся и редактироваться. Файлы в базе хранить не стоит — оставьте это промышленным системам, где необходима единая система контроля, репликации и т.п. Проше организовать хранилище на диске. С общим корнем, например /storage. Генерить уникальное имя файлу и путь к нему с учетом ИД владельца. Т.е. путь к файлу будет такой:
/storage/22/7622/qwertyuiop1234asd
где «7622» — ИД пользователя (конечно, если файлы имеют привязку в пользователю)
«22» — хэш-код, что б во-первых избежать огромного числа поддиректорий в stogare, а во-вторых в этом случае проще разносить storage на разные диски.
В целях экономии, фотографии при закачке резайзить до каких-то разумных размеров, т.к. большинство будет загружать фоты прямо с фотика.
С «микропостами» ничего хитрого придумывать не надо — обычная таблица. Для повышения производительности — кэширование на стороне сервера.
В свою бытность архитектором БД, разрабатывал достаточно серьезные базы. При разработке пользовался Power Designer'ом. Базовые принципы те же самые, что и для «маленьких» баз. Главное сложность — не утонуть в огромном количестве таблиц. На помощь приходит старая как мир техника — разделяй и властвуй. Т.е. разбить базу на составные части (модули), с большой «связаностью» внутри модуля и «слабыми» связями между модулями. Каждый модуль рисовать на отдельном листе, необходимые таблицы из других модулей показывать другим цветом и без перечисления полей (только квадратик с названием таблицы).
К примеру в какой-нибудь системе по учету товара можно выделить модули «юзер и права доступа», «товар», «баланс» и т.п. Соответственно при проектировании каждого модуля — внимание акцентируется уже на достаточно ограниченном наборе таблиц.
Вроде это тоже очевидно, но опять же практика показывает обратное — много раз видел схемы баз из сотни таблиц. Вся схема была на одном листе формата А1 и каждая таблица присутствовала в единственном экземпляре. Естественно такая таблица, как USER была связана практически с каждой второй таблицей и к ней вело порядка пятидесяти стрелочек, которые причудливо переплетались между собой. Единственная ценность такой схемы — нагнетать ужас на заказчика. Ибо с практической точки зрения работать с ней невозможно.
Еще хорошо придерживаться какой-то системы именования. К примеру с префиксами в именах таблиц:
ent_xxxxxx — обычная таблица с данными (от entity)
dct_xxxxxx — таблица-справочник (от dictionary)
ext_xxxxxx — таблица-расширение, из связи один-к-одному (от extention)
col_xxxxxx — связка многие-ко-многим (от collection)
Это опять же достаточно общие принципы. А единой статьи не эту тему, думаю не выйдет написать, т.к. слишком много частностей нужно учитывать. При разработке больших баз сталкиваешься с различными трудностями и ограничениями — решать их приходится в «индивидуальном порядке».
Эта статья во-первых крик души. А во вторых — этакий ликбез. Я не сомневаюсь, в квалификации хабра-людей и уверен, что ничего нового для них здесь нет. Но ведь у всех бывают знакомые, которым иногда приходится заниматься вещами далекими от их повседневных занятий. В частности если этим знакомым, по каким-то причинам, нужно сделать базу — можно смело посылать их на эту статью.
Вот для начала:
- найти все расстановки восьми ферзей, которые не бьют друг друга.
- первые 100 знаков числа e (число Эйлера, основание натур. логарифма)
- первые 100 знаков числа Пи (3.14 которое)
- деление 100-значных чисел
чуть посложнее:
- «компилятор формул». По строке с правильной арифм. формулой посчитать значение. Пример строки «-3 + (3/(4+2))^2».
- «выпуклая оболочка» На плоскость в произвольном порядке падают точки. Нужно после падения каждой точки выдавать площадь и периметр «натянутого на них» многоугольника
И поймите, я пропагандирую ночную работу. Просто при домашней работе в однокомнатной квартире и с маленьким ребенком это единственный выход, т.к. практически ни один из 30 пунктов реализовать на практике не получится.
Работайте ночью!
Сейчас вынуждено работаю дома. Это единственное действенное ср-во. Всякие «границы для своих близких» и т.п. — теоретическая идеализация редко достижимая на практике.
Интересно, о чем думал автор, когда писал последнюю строку? ;)
Отправили «большой» запрос (в смысле, долгий, который будет отражаться на прогресс-баре). И отдельными аякс-вызовами опрашивать сервер о состоянии этого «большого» запроса. Ну и соответственно отражать это состояние на прогресс-баре. Серверная часть, разумеется, должна давать адекватные ответы.
PS кстати — загрузка файла аякс-запросом не реализуется, но состояние загрузки отслеживается аяксом.
Может для чего-нибудь это и сгодится, но точно не для «индикатора загрузки» и «прогресс-бара».