Я работаю над проектом, в котором люди могут создавать плейлист и его хранить в localStorage как объекты. на данный момент все на стороне клиента.
поэтому теперь я хочу сделать скачок вперед, сделать систему входа пользователя (я могу сделать это, используя php mysql и fb connect или oauth system, любые другие предложения?). проблема заключается в том, чтобы решить, могу ли я создать базу данных sql для каждого пользователя и сохранить их список воспроизведения (со сведениями о медиа) или есть ли другой способ обойти. будет ли обработка большого количества баз данных проблемой для меня (с точки зрения скорости)?
как насчет создания только одного db следующим образом:
пользовательская база данных —> одна таблица, содержащая {user (первичный ключ) pass someotherInfo}, затем таблицы на USER {содержит плейлисты), 3-я таблица на список воспроизведения (содержащий идентификатор пользователя и информацию о носителе, какой может быть мой первичный ключ?)
Например: у меня 10 зарегистрированных пользователей, у каждого пользователя есть 2 плейлиста
1.table 1: 10 entries 2.table(s): username - playlists (10 tables) || i make one table with one field user other field playlist name 3.tables: each playlist - media info, owner (20 tables) или есть более простой способ?
Надеюсь, мой вопрос ясен.
PS: Я новичок в php и базе данных (так что это может быть очень глупо)
Удивленный большинство ответов, похоже, упустили вопрос, но я попробую это;
Это называется моделированием данных (как вы собираете кучу таблиц в базе данных вместе, чтобы выразить то, что вы хотите наилучшим образом), и не чувствуйте себя глупо за вопрос; есть люди, которые проводят все свои часы бодрствования и разрабатывают модели данных. Они чрезвычайно важны для благополучия любой системы, и они, по правде говоря, гораздо важнее, чем большинство людей отдают им должное.
Похоже, вы на правильном пути. Всегда полезно определить свои сущности и создать таблицу для каждого, поэтому в этом случае у вас есть пользователи и плейлисты и песни (например). Определите свои таблицы таким образом; USER, SONG, PLAYLIST.
Следующее – определение имен полей и таблиц (и, возможно, упрощенные названия, предложенные выше, являются, кстати, упрощенными). Некоторые из них представляют собой пространства имен faux (т. Е. MYAPP_USER, а не только USER), особенно если они знают, что модель данных будет расширяться и расширяться в одной и той же базе данных в будущем (или некоторые из-за того, что они знают, что это неизбежно), в то время как другие просто распространяются что им нужно.
Большой вопрос всегда будет касаться нормализации и различных проблем, связанных с этим, балансируя производительность против применимости, и есть тонны и тонны книг, написанных на эту тему, поэтому я не могу дать вам сколько-нибудь значимый ответ, но суть этого для меня является;
В какой момент поле данных в таблице будет достойно собственной таблицы? Например, вы можете создать свое приложение только с одной таблицей или двумя или 6 в зависимости от того, как вы хотите разделить свои данные. Здесь я думаю, что ваш вопрос действительно приходит.
Я бы сказал, что вы в значительной степени правильны в своих предположениях, что нужно иметь в виду согласованные соглашения об именах (и есть тонны мнений о том, как назвать идентификаторы). Для вашего приложения (с таблицами, упомянутыми выше), я бы сделал;
USER { id, username, password, name, coffee_preference } SONG { id, artist, album, title, genre } PLAYLIST { id, userid } PLAYLIST_ITEM { id, songid, playlistid, songorder }
Теперь вы можете использовать SQL, чтобы получить все плейлисты для пользователя;
SELECT * FROM PLAYLIST WHERE userid=$userid
Или получить все песни в плейлисте;
SELECT * FROM SONG,PLAYLIST_ITEM WHERE playlist_item.playlistid=$playlist.id AND song.id=playlist_item.songid ORDER BY playlist_item.songorder
И так далее. Опять же, томы были написаны по этому вопросу. Все дело в том, чтобы мыслить четко и семантически, задавая техническое решение. И у некоторых людей есть только это как карьера (например, DBA). Будет много мнений, особенно о том, что я здесь написал. Удачи.
Возможно, вам нужно иметь хороший учебник о том, как работать с php и mysql.
Это мой любимый PHP 101: PHP для абсолютного начинающего и для базы данных Базы данных и другие животные
Вы можете использовать либо базу данных SQL, такую как MYSQL или Postgresql, либо базу данных NOSQL, такую как MongoDB. У каждого есть свои плюсы и минусы, но поскольку вы, похоже, новичок, я собираюсь предложить MYSQL, потому что это то, с чем работают большинство новичков. Взгляните на эти статьи
http://www.redhat.com/magazine/007may05/features/mysql/
Конечно, вы можете чувствовать себя свободными от поиска в The Big G, поскольку там есть масса ресурсов.