Open source models database

Хочу написать простой скрипт каталога моделей, скрипт будет свободным, куски кода буду выкладывать прям в этом топике as is , и т.к. я не проф.программер, а простой любитель скорее, будет здорово если более опытные коллеги будут немного направлять советом, или просто ссылкой хорошей, на явные ошибки укажут коли...

Ну а потенциальные пользователи сего могут тут писать о своих пожеланиях, постараюсь все учесть(в разумных пределах).

На данный момент проектирую базу данных, и немного запутался с primary , foreign keys, скажите плиз, правильно ли я создаю таблицы и их связь?
=========
Структура базы mysql

Код: [развернуть]

mysql_query("CREATE TABLE models( models_id INT auto_increment, added DATE, category  TINYTEXT, name TINYTEXT, birthday TINYTEXT, astrology TINYTEXT, birthplace TINYTEXT, bio TEXT, ethnicity TINYTEXT, nationality TINYTEXT, haircolor TINYTEXT, eyecolor TINYTEXT, measurements TINYTEXT, height TINYTEXT, weight TINYTEXT, tattoos TINYTEXT, piercings TINYTEXT, rate INT, votes INT, pageurl TINYTEXT, thumburl  TINYTEXT, PRIMARY KEY (models_id) ) TYPE=INNODB") or die(mysql_error()); mysql_query("CREATE TABLE galleries( id int auto_increment, modelname INT, date DATE, url TINYTEXT, desc TINYTEXT, FOREIGN KEY (modelname) REFERENCES models (models_id) ) TYPE=INNODB" ) or die(mysql_error()); mysql_query("CREATE TABLE comments( id int auto_increment, modelname INT, date DATE, user TINYTEXT, comment  TEXT, FOREIGN KEY (modelname) REFERENCES models (models_id) ) TYPE=INNODB") or die(mysql_error());

===============
Форма Add Model()

Код: [развернуть]

<form enctype="multipart/form-data" action="add-model.php" method="post"> <table><tr> <td> Model Name: </td> <td> <input type="text" name="name"> </td> <td> Category: </td> <td> <select name="category" size="1"> <option value='A'>A</option> <option value='B'>B</option> <option value='C'>C</option> <option value='D'>D</option> <option value='E'>E</option> <option value='F'>F</option> <option value='G'>G</option> <option value='H'>H</option> <option value='I'>I</option> <option value='J'>J</option> <option value='K'>K</option> <option value='L'>L</option> <option value='M'>M</option> <option value='N'>N</option> <option value='O'>O</option> <option value='P'>P</option> <option value='Q'>Q</option> <option value='R'>R</option> <option value='S'>S</option> <option value='T'>T</option> <option value='U'>U</option> <option value='V'>V</option> <option value='W'>W</option> <option value='X'>X</option> <option value='Y'>Y</option> <option value='Z'”>Z</option> </select> </td> </tr> <tr> <td> Birth Day:</td> <td><input type="text" name="birthday"></td> <td>Astrological sign:</td> <td><input type="text" name="astrology"> </td> </tr> <tr> <td> Birth Place: </td> <td><input type="text" name="birthplace">  </td> <td>Ethnicity: </td> <td><input type="text" name="ethnicity"> </td> </tr> <tr> <td> Nationality: </td> <td><input type="text" name="nationality"> </td> <td>Hair Color: </td> <td><input type="text" name="haircolor"> </td> </tr> <tr> <td> Eyes Color: </td> <td><input type="text" name="eyecolor">  </td> <td>Measurements: </td> <td><input type="text" name="measurements"> </td> </tr> <tr> <td> Height: </td> <td><input type="text" name="height"> </td> <td>Weight: </td> <td><input type="text" name="weight"> </td> </tr> <tr> <td> Tatoos: </td> <td><input type="text" name="tattoos"> </td> <td>Piercing(s): </td> <td><input type="text" name="piercings"> </td> </tr> </table> Biography: <br> <textarea name="bio" rows="5" cols="72" value="Biography"></textarea> <br> Upload Thumb: <input type="file" name="thumb">  <br><br> <input type="submit" value="Add Model Profile"> <input type="reset" value="Reset Form !!! =)"> </form>

желающие могут предложить дополнительные поля, которые могут потребоваться данному скрипту, по вашему мнению.

Последний раз редактировалось: Ado.Blogs (16/01/11 в 12:20), всего редактировалось 4 раз(а)

INNODB - это хорошо.
PRIMARY KEY (name) - это плохо, PRIMARY KEY (model_id) - лучше.
Вообще для первичных ключей не стоит выбирать поля, несущие смысловую нагрузку для пользователя. Это гарантирует что: ПК будет уникальным и не NULL.

ты БД прямо из ПХП проектируешь чтоли Посмотри в сторону mysql workbench, или профессиональных сред проектирования вроде errwin или чего-нибудь подобного


З.Ы. Зачем ты это делаешь я спрашивать не буду

Yacc:

то есть делаю первое поле в первой таблице models_id с авто инкрементом
это будет типа так называемый суррогатный ПК, правильно?

а уже в остальных таблицах modelname делаю INT, и правлю FOREIGN KEY (modelname) REFERENCES models (models_id) таким образом.

я все правильно понял? теперь ПК будут в порядке, и база поменьше объемом...

taj: пару-пяток таблиц уж как нибудь в голове спроектировать можно.

Yacc писал:

INNODB - это хорошо.

ага, огромный проигрыш в производительности в данной базе

Типа того. Про индексы не забудь.

ibiz писал:

ага, огромный проигрыш в производительности в данной базе

Тут, как говорится, кто на что учился. Конечно за транзакционную целостность приходится платить, но выбирая между скоростью и надёжностью я выбираю надёжность.
А "тозрмоза" InnoDB это в 90% случаев ошибки проектирования базы и SQL-запросы, написанные уроженцами Индии.

Yacc писал:

Тут, как говорится, кто на что учился. Конечно за транзакционную целостность приходится платить, но выбирая между скоростью и надёжностью я выбираю надёжность. А "тозрмоза" InnoDB это в 90% случаев ошибки проектирования базы и SQL-запросы, написанные уроженцами Индии.

данный "простой скрипт каталога моделей" подразумевает основную нагрузку на SELECT

я вот сколько тестировал InnoDB, никак не смог даже приблизится к порядку быстродействия MyISAM

Yacc: можешь ли ты привести пример таблицы, индексов, и самих процедур по выборки данных из базы InnoDB с таймерами, чтоб можно было запустить тесты на своей машине?

что бы немного остудить ваш спор в контексте данного топика, скрипт будет создавать статичные файлы html, то есть нагрузка будет только при recompile файлов, ну при поиске еще может... так что нагрузка на SELECT я не думаю что будет велика.

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-…ks-part-1/

Ado.Blogs писал:

что бы немного остудить ваш спор.

Да тут не о чем спорить: если данные важны - InnoDB (или другой транзакционный двиг) и точка.

Ado.Blogs писал:

что бы немного остудить ваш спор в контексте данного топика, скрипт будет создавать статичные файлы html, то есть нагрузка будет только при recompile файлов, ну при поиске еще может... так что нагрузка на SELECT я не думаю что будет велика.

ну допустим надо будет пересоздать 1000 страниц, один транзакционный селект займет ну допустим 1сек, итого надо будет потратить 1000 секунд только на пересоздание страниц

Yacc писал:

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-…ks-part-1/

ниочем не говорит, я же не из пальца высасываю проблему производительности, а на практике столкнулся и не смог достичь хороших результатов, возможно делаю что-то не так, хочу понять и разобраться что

я не говорю, что innodb говно или около того, сам пользую mariadb на высоконагруженном проекте (~100к запросов минуту)

ibiz писал:

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

Я отсюда не вижу откуда ты высасываешь проблему.
Показывай тогда конфиги, базу, индексы, запросы, логи...

Цитата:

если данные важны - InnoDB (или другой транзакционный двиг) и точка.

Транзакции обычно при финансовых операциях используют, ну или в похожих системах учета. Использовать транзакции для базы моделей, это как ракету строить, что бы в магазин за пивком сгонять

К минусам innodb:
- если хостинг хренового качества, перегружен или дисковая система уныла, то потерять данные можно сразу и все кучей.
- на большом количестве данных, при постоянных выборках, гораздо медленнее myisam.

И вообще для open source код надо выкладывать не в топике, а где нибудь на гугл коде, где нормальный контроль версий и прочее

Stek писал:

Транзакции обычно при финансовых операциях используют, ну или в похожих системах учета.

То есть там, где данные важны? Если да, то не вижу повода для сарказма, кроме как желание затеять холивар.

Я вечно это слышу тут - "MyISAM быстрее, и все тут".

И потом меня просят глянуть в код какого сайта, посмотреть, что тормозит - это, естественно, оказывается кривейший запрос. Работающий поверх MyISAM.

Дело все-таки обычно не в MyISAM vs InnoDB, а в прокладке между креслом и клавиатурой. Просто MyISAM, как у меня сложилось впечатление, относится менее критично к оптимизации запросов и тьюнингу самого MySQL. То есть распиздяйски написанный select без индексов человеком, который не представляет себе как дизайнить базу, innodb убьет там, где MyISAM еще будет как-то тянуть и выплевывать что-то после 20 секунд работы. Я уж не говорю о том, что значительная часть программеров понятия не имеет, какие типы индексов бывают у MySQL, чем отличаются и когда их применять надо.

Прошу не думать, что я на кого конкретно намекаю - у каждого из нас, конечно, опыт свой. Я только своим делюсь.

А так - по теме хороший топег свежий на SOF

http://stackoverflow.com/questions/20148/myisam-versus-innodb

Цитата:

То есть там, где данные важны? Если да, то не вижу повода для сарказма, кроме как желание затеять холивар.

Ты в курсе что такое транзакция и для чего она используется ?
Если да, то объясни, зачем нужна транзакция при обновлении/вставки данных модели, даже если при этом задействовано несколько таблиц.

Цитата:

Дело все-таки обычно не в MyISAM vs InnoDB, а в прокладке между креслом и клавиатурой. Просто MyISAM, как у меня сложилось впечатление, относится менее критично к оптимизации запросов и тьюнингу самого MySQL.

Простой пример, есть таблица с 80к+ записей, там и тексты и числа, но выборка идет по паре числовых полей и дате, индексы везде есть. 95% там селекты. При большом числе запросов, это все отвечало медленно, иногда до 1 секунды на запрос. После конвертации в myisam , нагрузка сильно спала, выборка 0,1-0,2 секунды.

Х.з. конечно, можно сервер дополнительно тюнить, может там версия какая с багом или старая, но иногда нужны быстрые решения, нежели решение глобальной проблемы.

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

Ado.Blogs писал:

куски кода буду выкладывать прям в этом топике

ты серьёзно ?) имхо более правильнее баг треккер поднять для этого

Это что за категории такие во втором коде, они должны автоматически браться на основе имени модели

Stek писал:

Простой пример, есть таблица с 80к+ записей, там и тексты и числа, но выборка идет по паре числовых полей и дате, индексы везде есть. 95% там селекты. При большом числе запросов, это все отвечало медленно, иногда до 1 секунды на запрос. После конвертации в myisam , нагрузка сильно спала, выборка 0,1-0,2 секунды. Х.з. конечно, можно сервер дополнительно тюнить, может там версия какая с багом или старая, но иногда нужны быстрые решения, нежели решение глобальной проблемы.

Или просто писать нормально сразу. Я о чем - о том, что если действительно наличествует существенная разница в производительности в сторону MyISAM - ты просто что-то делаешь не так. Это такой вот rule of thumb.

Вот смотри - в данном случае ТС выделил для категории поле типа TINYTEXT. Ну ладно в его случае там статика генерится, так что как будет это в результате - не совсем понятно, но в 90% случаев люди так всегда делают, или похоже. Вместо того, чтобы вынести это в отдельную таблицу и сослаться по первичному ключу. Ну и таких кривостей полно везде и всегда, куда ни ткнись, и innodb, заточенный, простите за выражение, под педантов-архитекторов, будет чувствовать себя хуже. Тут ведь найдутся и люди, которые будут утверждать, что "база тормозит", а на самом деле наиболее высокопроизводительный способ - держать все в текстовых файлах. А все потому, что базой пользуются, подразумевая, что она должна сама по себе как-то вот так быстро работать, а в детали вдаваться не нужно. Вы меня понимаете, мистер Андерсон?

Никого не надеюсь переубедить, просто вечернее ворчание ))

Stek писал:

Ты в курсе что такое транзакция и для чего она используется ?

В курсе - давно использую SQL Server с поддержкой транзакций на уровне языка. И вообще нетранзакционных баз не бывает. Это сказка для бедных.

А то, что ты там говоришь тормозило у тебя, так это тормозило у тебя.

Цитата:

В курсе - давно использую SQL Server с поддержкой транзакций на уровне языка. И вообще нетранзакционных баз не бывает. Это сказка для бедных

Тогда зачем ты несешь хуйню, что по сравнению с myisam, innodb хорошо тем, что тут есть транзакции ? Ты уж определись в своих мыслях.

Цитата:

А то, что ты там говоришь тормозило у тебя, так это тормозило у тебя.

Спасибо КЭП

Yacc писал:

Я отсюда не вижу откуда ты высасываешь проблему. Показывай тогда конфиги, базу, индексы, запросы, логи...

ок
дано 3 таблицы
names - действующие имена с присвоенными id
user_rank - ранк пользователя
data - внешняя независимая таблица по которой идет сверка и поиск отсутствующих в таблице 'names' пользователей с рейтингом больше 100
во каждой таблице записей ~10m
MyISAM работает быстрее InnoDB

Код: [развернуть]

CREATE TABLE `names` (   `id` int(8) NOT NULL auto_increment,   `name` varchar(66) NOT NULL default '',   PRIMARY KEY  (`id`),   UNIQUE KEY `name` (`name`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE `data` (   `name` varchar(66) NOT NULL default '',   `birthday` date NOT NULL default '0000-00-00',   `die` date NOT NULL default '0000-00-00',   `ver` tinyint(2) NOT NULL default '0',   KEY `name` (`name`(8)),   KEY `birthday` (`birthday`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; CREATE TABLE `user_rank` (   `id` int(11) NOT NULL default '0',   `time_check` tinyint(1) NOT NULL default '0',   `rank` int(8) NOT NULL default '0',   UNIQUE KEY `id_cy` (`id`,`time_check`),   UNIQUE KEY `id` (`id`),   KEY `time_check` (`time_check`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8; SELECT names.id, names.name, user_rank.rank FROM names LEFT JOIN data ON names.name=data.name LEFT JOIN user_rank ON user_rank.id=names.id WHERE data.name IS NULL AND user_rank.rank >= 100 LIMIT 50

ibiz писал:

MyISAM работает быстрее InnoDB

На сколько быстре?

innodb_flush_logs_at_trx_commit = 1 ?

Так это, а зачем тебе InnoDB? Ведь MyISAM быстрее.

Yacc писал:

На сколько быстре? innodb_flush_logs_at_trx_commit = 1 ?

быстрее на порядок, 30сек против 300сек...

Цитата:

innodb additional mem pool size 2,097,152 innodb autoextend increment 8 innodb buffer pool awe mem mb 0 innodb buffer pool size 16,777,216 innodb checksums ON innodb commit concurrency 0 innodb concurrency tickets 500 innodb data file path ibdata1:10M:autoextend innodb data home dir innodb adaptive hash index ON innodb doublewrite ON innodb fast shutdown 1 innodb file io threads 4 innodb file per table OFF innodb flush log at trx commit 1 innodb flush method innodb force recovery 0 innodb lock wait timeout 50 innodb locks unsafe for binlog OFF innodb log arch dir innodb log archive OFF innodb log buffer size 8,388,608 innodb log file size 5,242,880 innodb log files in group 2 innodb log group home dir ./ innodb max dirty pages pct 90 innodb max purge lag 0 innodb mirrored log groups 1 innodb open files 300 innodb rollback on timeout OFF innodb support xa ON innodb sync spin loops 20 innodb table locks ON innodb thread concurrency 8 innodb thread sleep delay 10,000 innodb use legacy cardinality algorithm ON

Yacc писал:

Так это, а зачем тебе InnoDB? Ведь MyISAM быстрее.

мне InnoDB нужен для больших баз