kapitansky

> так как пхп изначально был спроектирован для короткого времени работы из-за чего возможна беда с памятью.
Оба языка — скриптовые.

Потребление ресурсов у PHP будет ниже, чем у Python.

Скорость работы приблизительно одинаковая.

На Python, скорее всего реализовать будет проще.

А вообще, по-хорошему, такие вещи не делаются ни на PHP, ни на Python. Я бы, на вашем месте, смотрел бы в сторону Java — на ней будет проще, чем на С, а скорость будет примерно такая же, а может и выше (из-за «гениальности» JVM).

Попробуйте сервис join.me
* прост
* не требует установки
* экран шарится через браузер
* хорошее качество картинки
* возможность чата с viewers
* возможность передачи управления viewer'у

Cогласен с учителем Norraxx (17 мая в 23:58 «Мой учитель по Java мне говорил: «Каждый раз, когда вы используете hash как id, вы убиваете котёнка.»») и VitaZheltyakov (md5-хэш в качестве id следует использовать только, если он заменяет составной ключ (несколько ключевых полей). В остальных случаях мы используем int (bigint) с unsigned и auto_increment). Причём только в том случае если суммарная сложность поиска по нескольким ключевым полям будет выше, чем у хеша…

Чем меньше ключ — тем быстрее происходит поиск по нему, поэтому всегда надо стремиться минимизировать его размер.

Поиск по числовому ключу зачастую много быстрее (бывает, что и до 4х раз быстрее, возможно и ещё быстрее) нежели поиск по числу той же длинны… и это верно не только для реляционных СУБД, но и для подавляющего большинства языков программирования (вполне вероятно, что потребуется искать в множестве, полученном ранее из БД).

Исходя из вашей задачи, для начала, в качестве типа PK я бы выбрал unsigned mediumint (16,777,215 — 1 записей)- его всегда можно будет расширить до int, а затем и bigint (если, конечно, это потребуется).

Если MySQL, то, как мне кажется, движок MyISAM — не самый лучший выбор (из-за потабличной блокировки) — правильным решением будет комбинировать InnoDB и MyISAM (в тех случаях когда будет требоваться выводить большое кол-во инфы, а также пользовать втроенный механизм полнотекстового поиска (тк в InnoDB его нет и придётся «изобретать» свои/использовать чужие механизмы)). Кроме того с версии 5.5 в MySQL реализованна возможность создания noSQL-хранилищ (если вас не устраивает memcache (и прочие) которые легко интегрируются с php).

Также могу порекомендовать обратить своё внимание на СУБД Firebird.

По поводу Ms SQL — очень мощная база, но разумеется с ней удобнее работать с использованием C# и продуктов MS (например Visual Studio) — это позволит существенно сократить время на разработку.

Как вы уже, наверное, знаете php не самое лучшее средство для реализации систем с высокой нагрузкой (здесь придётся повоевать), ну и придётся принимать решение по поводу модели программирования — не думаю, что ОО модель будет лучшим выбором. Возможно стоит обратить своё внимание на Java или C#…

Ну и разумеется структура БД крайне важна — в случае неправильного выбора — не спасёт ни одна СУБД. Но для того, чтобы придти к оптимальной для данного решения структуре — надо понимать что именно вы собираетесь реализовывать, но я, если я правильно понимаю, то у вас нет этого понимания. Если позволите — мой совет начать именно с этого, а не с выбора СУБД.

Здравствуйте!
Как Вы понимаете, подходящее Вам решение, зависит в первую очередь от задач, о которых вы не упомянули в своём вопросе.
Я бы посоветовал — CMS typo3, если же Вас не смущает большой объём документации (в основном на английском, но есть достаточно много переведённых мануалов, например тут ). Очень мощная и гибкая система, но она не будет самым лучшим выбором для реализации проектов «аля социальная сеть» (хотя её система кеширования постоянно улучшается и, по идее её можно настроить и под эти задачи, но придётся «попотеть»).
Вот несколько ссылок по мультиязычности:
Frontend Localization Guide (Russian)
Multi language sites in TYPO3 (Лично я использую второй метод, описанный в этом руководстве).