d1gi: Сторонникам параноидального ООП, где каждая рюшечка должна быть оформлена в виде каскада наследуемых классов и обязательно всё подкрепрено тестированием т.е. тестирование и ооп это хорошо, но всему есть мера.
Вы видимо не очень хорошо представляете себе, что значит ООП. Наследовние, к примеру, далеко не всегда приветствуется, а тестирование(юнит-тесты, как я понимаю) вовсе не имеют отношения к ООП, это TDD методология, которую я ,кстати, очень уважаю и внедряю по возможности в своих проектах, очень упрощает жизнь в дальнейшем.
А делали ли вы сравнительную характеристику с уже существующими решениями на рынке? Плюсы, минусы? Будет ли это Open Source?
[umka: ;9810366]И величина id тут вообще ни при чём
присоединяюсь, индексы рулят. 20кк далеко не предел, я работал и с несколькотеррабайтными БД и ничего, главное грамотно продумать структуру(в вашем случае - очевидно), поставить индексы и наслаждаться
Как я понимаю речь идет о Windows.Forms. У формы есть один и только один UI поток и если кто-то меняет что-то поток соответственно блокируется и форма "подвисает", т.е. перестает обрабатывать сообщения. Чтобы этого избежать можно вызывать метод ProcessMessages, который принудительно заставляет формы обрабатывать входящие сообщения. Если мы говорим о синхронизации нескольких потоков, которые могут менять состояние окна, то логично организовать стек вызовов дабы избежать конфликтов.
netwind: если файлы конвертировать в бд не как есть, а нормализируя базу, то объем может получиться меньше.
Позволю не согласится. Если сравнивать объем ненормализованной БД и нормализованной - да. Если же сравнивать объем исходных данных и объем тех же данных, помещенных в БД - нет.
iopiop: хранить метаданные вместе данными - зачем?
Полностью согласен, давайте для начала отделим "мух от котлет"
Файлы так файлы. Допустим.
rommer: У меня возникла следующая идейка:
Идейка, скажем так, на уровне студента первого курса, без обид.
Для поиска по метаданным строим индекс. Вот по индексу уже и будем бродить.
Тут мы приближаемся к так называемым файловым базам данных(типа Paradox, если конечно кто еще помнит :) ). Тут нужно обязательно учесть, что индекс нужно будет перестраивать и восстанавливать в случае сбоя.
Мороки конечно будет достаточно, но вполне реализуемо. Как устроены индексы я думаю понятно, в любом случае вопрос давно описан в массе литературы.
Если говорить про БД, то хранить те же файлы в самой БД не всегда целесообразно. Достаточно хранить ссылку на файл. Тут и скачка напрямую и уменьшение размера таблицы.
iopiop: структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.
Можно ТАК построить индексы, что скорость наоборот упадет :) Извините за оффтоп.
Так же соглашусь с тем, что найти хостинг без БД надо еще суметь. Обычно БД уже предустановлена. А далее все что нужно - сделать скрипт типа install.(php, aspx и т.п.) который всю работу по инсталляции и сделает.
Возможно ShopCMS, но я не уверен
Если ники "захардкожены" не проще ли их вынести в отдельную таблицу? И запрос проще станет и менять в последующем проще.
Сторонникам параноидального ООП, где каждая рюшечка должна быть оформлена в виде каскада наследуемых классов и обязательно всё подкрепрено тестированием т.е. тестирование и ооп это хорошо, но всему есть мера.
Вы видимо не очень хорошо представляете себе, что значит ООП. Наследовние, к примеру, далеко не всегда приветствуется, а тестирование(юнит-тесты, как я понимаю) вовсе не имеют отношения к ООП, это TDD методология, которую я ,кстати, очень уважаю и внедряю по возможности в своих проектах, очень упрощает жизнь в дальнейшем.
А делали ли вы сравнительную характеристику с уже существующими решениями на рынке? Плюсы, минусы? Будет ли это Open Source?
;9810366]И величина id тут вообще ни при чём
присоединяюсь, индексы рулят. 20кк далеко не предел, я работал и с несколькотеррабайтными БД и ничего, главное грамотно продумать структуру(в вашем случае - очевидно), поставить индексы и наслаждаться
Как я понимаю речь идет о Windows.Forms. У формы есть один и только один UI поток и если кто-то меняет что-то поток соответственно блокируется и форма "подвисает", т.е. перестает обрабатывать сообщения. Чтобы этого избежать можно вызывать метод ProcessMessages, который принудительно заставляет формы обрабатывать входящие сообщения. Если мы говорим о синхронизации нескольких потоков, которые могут менять состояние окна, то логично организовать стек вызовов дабы избежать конфликтов.
З.Ы. я создал тему по .net вот тут: /ru/forum/677899
Если что - обращайтесь.
если файлы конвертировать в бд не как есть, а нормализируя базу, то объем может получиться меньше.
Позволю не согласится. Если сравнивать объем ненормализованной БД и нормализованной - да. Если же сравнивать объем исходных данных и объем тех же данных, помещенных в БД - нет.
http://www.shop-script.ru/support/help/sef-urls-enable.html
1-я ссылка в гугле по запросу "Shop-Script ЧПУ", извините
Соглашусь насчет фиолета, от себя - убрать часы сверху, моветон.
Бррр, какой жуткий код, извините.
Если на один ящик приходит - значит sendmail отработал.
ИМХО - проблема на стороне клиента.
Если вы говорите, что ошибки есть, то напишите какие собственно.
Вставлю свои 5 копеек.
хранить метаданные вместе данными - зачем?
Полностью согласен, давайте для начала отделим "мух от котлет"
Файлы так файлы. Допустим.
У меня возникла следующая идейка:
Идейка, скажем так, на уровне студента первого курса, без обид.
Для поиска по метаданным строим индекс. Вот по индексу уже и будем бродить.
Тут мы приближаемся к так называемым файловым базам данных(типа Paradox, если конечно кто еще помнит :) ). Тут нужно обязательно учесть, что индекс нужно будет перестраивать и восстанавливать в случае сбоя.
Мороки конечно будет достаточно, но вполне реализуемо. Как устроены индексы я думаю понятно, в любом случае вопрос давно описан в массе литературы.
Если говорить про БД, то хранить те же файлы в самой БД не всегда целесообразно. Достаточно хранить ссылку на файл. Тут и скачка напрямую и уменьшение размера таблицы.
структура БД очень рыхлая + куча индексов, которые обычно занимают места больше чем собственно данные. Все в угоду скорости.
Можно ТАК построить индексы, что скорость наоборот упадет :) Извините за оффтоп.
Так же соглашусь с тем, что найти хостинг без БД надо еще суметь. Обычно БД уже предустановлена. А далее все что нужно - сделать скрипт типа install.(php, aspx и т.п.) который всю работу по инсталляции и сделает.
Как то так.