Изучение моделирования данных (как совместить разумную базу данных) - PullRequest
0 голосов
/ 30 мая 2011

Я работаю над проектом, в котором люди могут создавать плейлист и хранить его в localStorage в виде объектов.на данный момент все на стороне клиента.

, так что теперь я хотел бы сделать шаг вперед, сделать систему входа в систему пользователя (я могу сделать это с помощью php mysql и fb connect или oauth, любые другие предложения?),проблема состоит в том, чтобы решить, создать ли я базу данных sql для каждого пользователя и сохранить их плейлист (с информацией о мультимедиа) или есть какой-то другой способ обойти.Будет ли для меня проблемой большое количество баз данных (с точки зрения скорости)?

как насчет того, чтобы создать только одну БД следующим образом:

база данных пользователей ---> одна таблица, содержащая{пользователь (первичный ключ) 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 и базе данных (так что это может быть очень глупо)

Ответы [ 3 ]

2 голосов
/ 30 мая 2011

Удивило большинство ответов, похоже, пропустил вопрос, но я попробую;

Это называется моделированием данных (как вы объединяете кучу таблиц в базе данных, чтобы наилучшим образом выразить то, что вы хотите), и не стесняетесь спрашивать; Есть люди, которые проводят все свои часы бодрствования, настраивая и моделируя данные. Они чрезвычайно важны для благополучия любой системы, и, по правде говоря, они гораздо важнее, чем большинство людей доверяют им.

Звучит так, будто вы на правильном пути. Это всегда хороший совет, чтобы определить свои сущности и создать таблицу для каждого, так что в этом случае у вас есть пользователи, плейлисты и песни (например). Определите ваши таблицы таким образом; ПОЛЬЗОВАТЕЛЬ, ПЕСНЯ, ПЛЕЙЛИСТ.

Следующим шагом является определение имен полей и таблиц (и, возможно, предложенные выше упрощенные имена, ну, в общем, упрощенные). Некоторые вводят ложные пространства имен (т. Е. 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). Будет много мнений, особенно о том, что я здесь написал. Удачи.

1 голос
/ 30 мая 2011

Может быть, вам нужно хорошее руководство по работе с php и mysql.

Это мой любимый PHP 101: PHP Для абсолютного новичка и для базы данных Базы данных и другие животные

0 голосов
/ 30 мая 2011

Вы можете использовать базу данных SQL, такую ​​как MYSQL или Postgresql, или базу данных NOSQL, такую ​​как MongoDB.У каждого есть свои плюсы и минусы, но так как вы кажетесь новичком, я собираюсь предложить MYSQL, потому что именно с этим работает большинство новичков.Взгляните на эти статьи

http://dev.mysql.com/tech-resources/articles/mysql_intro.html http://www.redhat.com/magazine/007may05/features/mysql/

Конечно, вы можете свободно выполнять поиск в The Big G, поскольку там есть множество ресурсов.

...